Просто о смарт-контрактах

Отличия обычного контракт от смарт-контракта.

Рассмотрим бытовой пример. Представьте группу лиц, которая желает установить некоторые правила и условия распределения ценностей, а также определенным механизмом гарантировать выполнение этого распределения по заданным правилам и условиям. Тогда они собирались вместе, составляли бумагу, на которой записывали свои идентификационные данные, условия, вовлеченные ценности, ставили дату и подписывались. Этот контракт также заверяла доверенная сторона, например, нотариус. Далее, эти люди расходились в разные стороны со своей бумажной копией такого контракта и начинали выполнять какие-то действия, которые могли не соответствовать самому контракту, то есть они делали одно, а на бумаге заверено, что должны делать совершенно другое. И как выходить из этой ситуации? Фактически нужно кому-то из участников группы брать эту бумагу, брать какие-то доказательства, нести в суд и добиваться соответствия между контрактом и фактическими действиями. Довольно часто добиться справедливого выполнения этого контракта бывает сложно, что приводит к неприятным последствиям.

Что же можно сказать про смарт-контракты? Они объединяют в себе и возможность написания условий контракта, и механизм строгого их выполнения. Если условия были заданы и была подписана соответствующая транзакция или запрос, то после принятия этого запроса или транзакции уже невозможно изменить условия или повлиять на их выполнение.

Присутствует один валидатор или целая сеть, а также база данных, которая хранит все смарт-контракты, которые поступали на выполнение в строгой хронологической последовательности. Еще важно, что эта база данных должна содержать все условия-триггеры для выполнения смарт-контракта. Кроме того, она должна учитывать ту самую ценность, распределение которой описано в контракте. Если это касается некоторой цифровой валюты, значит эта база данных должна учитывать ее.

Иначе говоря, валидаторы смарт-контрактов должны иметь доступ ко всем данным, которыми оперирует смарт-контракт. Например, одна база данных должна использоваться для учета одновременно цифровых валют, балансов пользователей, транзакций пользователей и временных меток. Тогда в смарт-контракте условием может быть баланс пользователя в определенной валюте, наступление некоторого времени или факт осуществления некоторой транзакции, но не более того.

Читайте статтю: Трудовий контракт спортсмена: особливості укладення та розірвання

Определение смарт-контракта

Вообще, сама терминология была придумана исследователем Nick Szabo и впервые применена в 1994 году, а задокументирована была в 1997 году в статье, которая описывает саму идею смарт-контрактов.

Смарт-контракты подразумевают, что выполняется некоторая автоматизация распределения ценности, которая может зависеть только от тех условий, которые заранее предустановлены. В самом простом варианте это выглядит, как контракт со строго заданными условиями, который подписан определенными сторонами.

Смарт-контракты призваны минимизировать доверие третьим сторонам. Иногда полностью исключается центр принятия решений, от которого все зависит. Кроме того, для таких контрактов проще проводить аудит. Это является следствием некоторых особенностей проектирования такой системы, но чаще всего мы понимаем под смарт-контрактом децентрализованную среду и наличие функций, позволяющих любому желающему проанализировать базу данных и провести полный аудит выполнения контрактов. Таким образом гарантируется защита от изменений данных задним числом, которые повлекут за собой изменения в выполнении самого контракта. Оцифровка большинства процессов при создании и запуске смарт-контракта часто упрощает технологию и стоимость их реализации.

Простой пример

Давайте рассмотрим очень простой пример. Он поможет приблизиться к пониманию функциональных возможностей смарт-контрактов, а также лучше ориентироваться, в каких случаях их стоит применять.

Итак, у нас есть некоторый покупатель и есть интернет-магазин. Покупатель хочет купить монитор в этом магазине. В самом простом случае покупатель оформляет и отправляет платеж, а интернет-магазин принимает его, подтверждает, после чего отправляет товар. Однако в этой ситуации присутствует необходимость большого доверия — покупатель должен на всю стоимость монитора доверять интернет-магазину. Поскольку интернет-магазин может иметь низкую репутацию в глазах покупателя, то существует риск, что по каким-то причинам после приема платежа магазин откажет в обслуживании и не отправит товар покупателю. Поэтому покупатель задается вопросом (соответственно, и интернет-магазин задается этим вопросом), что можно в этом случае применить, для того чтобы минимизировать такие риски и сделать более надежными подобные сделки.

Можно предоставить возможность покупателю и продавцу независимо друг от друга выбрать медиатора. Есть множество людей, которые занимаются решением спорных вопросов. И наши участники могут выбрать из общего списка медиаторов того, которому одновременно будут доверять. Вместе они создают multisignature адрес 2 из 3, где есть три ключа и необходимы две подписи любыми двумя ключами, чтобы потратить монеты с этого адреса. Один ключ будет принадлежать покупателю, второй — интернет-магазину, а третий — медиатору. И на такой multisignature адрес покупатель отправит сумму, необходимую для оплаты монитора. Теперь, когда продавец видит, что деньги на некоторое время заблокированы на multisignature адресе, который зависит от него, он смело может отправлять монитор почтой.

Далее, покупатель получает посылку, осматривает товар и принимает решение об окончательной покупке. Он может быть полностью согласен с предоставленным обслуживанием и подписать транзакцию своим ключом, где он передает монеты с multisignature адреса продавцу, а может быть чем-то недоволен. Во втором случае он связывается с медиатором для составления альтернативной транзакции, которая по-другому будет распределять эти монеты.

Допустим, монитор приехал немного поцарапанный и в комплекте не лежал кабель для подключения к компьютеру, хотя на сайте интернет-магазина было написано, что кабель должен входить в комплект. Тогда покупатель собирает доказательства, необходимые для того, чтобы доказать медиатору, что его обманули в этой ситуации: он делает скриншоты сайта, делает фотографию чека с почты, делает фотографию царапин на мониторе и показывает, что пломба была сорвана и кабель вытащили. Интернет-магазин в свою очередь собирает свои доказательства и передает их медиатору.

Медиатор заинтересован в том, чтобы удовлетворить одновременно и возмущение покупателя, и интересы интернет-магазина (дальше будет понятно, почему). Он составляет такую транзакцию, в которой монеты с multisignature адреса будут тратиться в некоторой пропорции между покупателем, интернет-магазином и медиатором, так как он берет себе часть в качестве вознаграждения за свою работу. Допустим, 90% всей суммы пойдет продавцу, 5% медиатору и 5% компенсации покупателю. Эту транзакцию медиатор подписывает своим ключом, но она еще не может быть применена, потому что для этого нужно две подписи, а стоит только одна. Такую транзакцию он отправляет и покупателю, и продавцу. Если хотя бы один из них будет удовлетворен таким вариантом перераспределения монет, то транзакция будет до-подписана и распространена в сеть. Для ее валидации достаточно, чтобы один из участников сделки согласился с вариантом медиатора.

При этом важно изначально выбрать медиатора так, чтобы оба участника доверяли ему. В таком случае он будет действовать независимо от интересов одного либо другого и объективно оценит ситуацию. Если же медиатор не предоставляет такой вариант распределения монет, который удовлетворит хотя бы одного участника, тогда, договорившись вместе, и покупатель, и интернет-магазин могут переправить монеты на новый multisignature адрес, поставив свои две подписи. Новый multisignature адрес будет составлен уже с другим медиатором, который, возможно, будет более компетентен в вопросе и предоставит лучший вариант.

Читайте статтю: Інвестування через форвард. Простими словами про незрозуміле

Пример с общежитием и холодильником

Давайте рассмотрим более сложный пример, который отображает возможности смарт-контракта более явно.

Допустим, есть трое ребят, которые недавно заселились в одну комнату в общежитии. Они втроем заинтересованы в том, чтобы купить в свою комнату холодильник, которым они будут совместно пользоваться. Один из них вызвался собрать необходимую сумму для покупки холодильника и вести переговоры с продавцом. Однако они относительно недавно познакомились друг с другом и достаточного доверия между ними нет. Очевидно, что двое из них рискуют, отдавая деньги третьему. Кроме того, им нужно достичь согласия в выборе продавца.

Они могут выбрать медиатора, который проконтролирует выполнение сделки и уладит спорные вопросы, если такие возникнут. Тогда, договорившись, они составляют смарт-контракт и прописывают в нем определенные условия.

Первое условие заключается в том, что до наступления определенного времени, допустим в течение одной недели, на соответствующий аккаунт смарт-контракта должны поступить три платежа с определенных адресов на определенную сумму. Если этого не происходит, смарт-контракт прекращает свое выполнение и возвращает монеты всем участникам. Если же условие выполняется, тогда задаются значения идентификаторов продавца и медиатора, а также проверяется условие, что все участники согласны с выбором продавца и медиатора. Когда все условия будут выполнены, то дальше средства будут переведены на указанные адреса. Подобный подход может обезопасить участников от мошенничества с любой стороны и вообще исключает необходимость доверять.

Мы видим на этом примере сам принцип, что такая возможность пошагово задавать параметры для выполнения каждого условия позволяет создавать системы любой сложности и глубины вложенных уровней. Кроме того, сначала в смарт-контракте можно определить первое условие, а только после его выполнения уже задавать параметры для следующего условия. Иначе говоря, формально условие прописывается, а параметры для него могут задаваться уже во время его работы.

Классификация смарт-контрактов

Для классификации можно задавать разные группы критериев. Однако на данный момент развития технологий актуальными являются четыре из них.

Смарт-контракты можно отличать по среде выполнения, которая может быть либо централизованной, либо децентрализованной. В случае децентрализации мы имеем намного большую независимость и отказоустойчивость при выполнении смарт-контрактов.

Их также можно отличать по процессу задания и выполнения условий: они могут быть произвольно программируемые, ограниченные или предустановленные, т. е. строго типизированные. Когда на платформе смарт-контрактов существует только 4 определенных смарт-контракта, параметры к ним можно задавать произвольным образом. Соответственно, задавать их намного проще: мы выбираем контракт из списка и передаем параметры.

По способу инициирования существуют автоматизированные смарт-контракты, то есть при наступлении определенных условий они самоисполняются, а бывают такие контракты, в которых условия заданы, но платформа не проверяет автоматически их выполнение, для этого их нужно отдельно инициировать.

Кроме того, смарт-контракты различаются по уровню приватности. Они могут быть либо полностью открытые, либо частично, либо полностью конфиденциальные. Последнее значит, что сторонние наблюдатели не видят условия смарт-контрактов. Однако тема приватности очень обширная и ее лучше рассмотреть отдельно от текущей статьи.

Ниже мы подробнее остановимся на первых трех критериях, чтобы внести больше ясности в понимание текущей темы.

Смарт-контракты по среде выполнения

По среде выполнения различают централизованные и децентрализованные платформы смарт-контрактов. В случае централизованных цифровых контрактов используется один сервис, где существует только один валидатор и может быть служба резервного копирования и восстановления, которая так же централизованно управляется. Есть одна база данных, которая хранит всю необходимую информацию для задания условий смарт-контракта и распределения той ценности, которая учитывается в этой самой базе данных сервиса. У такого централизованного сервиса есть клиент, который определенными запросами задает условия и пользуется такими контрактами. Из-за того, что платформа централизованная, механизмы аутентификации могут быть менее надежными, чем в криптовалютах.

В качестве примера можно взять провайдеров мобильной связи (разных мобильных операторов). Допустим, определенный оператор ведет на своих серверах централизованным образом учет трафика, который может передаваться в разных форматах, например, в виде голосовых звонков, передачи SMS, трафика мобильного интернета, и по разным стандартам, а также ведет учет средств на балансах пользователей. Соответственно, провайдер мобильной связи может составлять контракты по учету предоставляемых услуг и их оплате с разными условиями. В таком случае легко задаются условия по типу “отправь SMS с таким-то кодом на такой-то номер и получишь такие-то условия распределения трафика”.

Можно еще один пример привести: традиционные банки с расширенной функциональностью интернет-банкинга и такие очень простые контракты, как регулярные платежи, автоматическая конвертация входящих платежей, автоматическое отчисление процента на указанный счет и т. п.

Если речь идет о смарт-контрактах с децентрализованной средой выполнения, тогда мы имеем группу валидаторов. В идеальном случае валидатором может стать вообще кто угодно. За счет протокола синхронизации базы данных и достижения консенсуса мы имеем некоторую общую базу данных, которая будет хранить теперь уже все транзакции со строго описанными контрактами, а не какие-то условные запросы, форматы которых часто меняются, а открытой спецификации нет. Здесь транзакции будут содержать инструкции по выполнению контракта в соответствии со строгой спецификацией. Эта спецификация открыта и, следовательно, сами пользователи платформы могут проводить аудит и валидировать смарт-контракты. Здесь мы видим, что децентрализованные платформы превосходят централизованные по независимости и отказоустойчивости, но их проектирование и обслуживание при этом гораздо сложнее.

Смарт-контракты по способу задания и выполнения условий

Теперь разберем подробнее, как смарт-контракты могут отличаться по способу задания и выполнения условий. Здесь обратим внимание на смарт-контракты, которые программируются произвольно и полные по Тьюрингу. Полный по Тьюрингу смарт-контракт позволяет задавать практически любые алгоритмы в качестве условий выполнения контракта: прописывать циклы, какие-то функции расчета вероятностей и тому подобное — вплоть до своих собственных алгоритмов электронной подписи. В данном случае имеется в виду действительно произвольное написание логики.

Выделяют также произвольные смарт-контракты, но не полные по Тьюрингу. Сюда можно отнести Биткоин и Лайткоин со своим скриптом. Имеется в виду, что можно в произвольном порядке использовать только определенные операции, но уже нельзя написать циклы и собственные алгоритмы.

Кроме того, есть такие платформы смарт-контракта, которые реализуют заранее предустановленные смарт-контракты. К ним можно отнести Bitshares и Steemit. Bitshares имеет целый ряд смарт-контрактов для торговли, управления аккаунтами, управления самой платформой и ее параметрами. Steemit — похожая платформа, но она ориентирована уже не на выпуск токенов и торговлю, как Bitshares, а на ведение блогов, т. е. она хранит и обрабатывает контент децентрализованным образом.

К произвольным полным по Тьюрингу контрактам можно отнести платформу Ethereum и RootStock, которая еще находится на стадии разработки. Поэтому далее мы чуть детальнее остановимся на платформе смарт-контрактов Ethereum.

Пользуйтесь консультацией: В ЧЕМ ФИШКА SMART-КОНТРАКТОВ?

Смарт-контракты по способу инициации

По способу инициации смарт-контракты тоже можно разделить минимум на две группы: автоматизированные и ручные (не автоматизированные). Для автоматизированных характерно, что при всех известных параметрах и наступивших условиях, смарт-контракт полностью выполняется автоматически, то есть не требует отправки каких-то дополнительных транзакций и траты дополнительной комиссии при каждом следующем выполнении. Сама платформа имеет все данные, для того чтобы рассчитать, каким образом смарт-контракт завершится. Логика там не произвольная, а заранее заданная и все это предсказуемо. То есть заранее можно оценить сложность выполнения смарт-контракта, использовать какую-то константную комиссию для него и все процессы по его выполнению проходят более эффективным образом.

Для смарт-контрактов, которые программируются произвольным образом, выполнение не автоматизировано. Для инициирования такого смарт-контракта фактически на каждом шаге нужно создавать новую транзакцию, которая будет вызывать уже следующий этап выполнения или следующий метод смарт-контракта, оплачивать соответствующую комиссию и дожидаться подтверждения транзакции. Выполнение может завершиться успешно или нет, потому что код смарт-контракта произвольный и могут появляться какие-то непредсказуемые моменты, такие как вечный цикл, нехватка каких-то параметров и аргументов, необработанные исключительные моменты и т. п.

Источник: distributedlab.com

Фото: Medium