В этой статье мы рассмотрим, что такое смарт-контракты, какие они бывают, познакомимся с разными платформами смарт-контрактов, их особенностями, а также обсудим, как они устроены и какие преимущества могут в себе нести. Данный материал будет очень полезен для читателей, которые недостаточно хорошо знакомы с темой смарт-контрактов, но хотят приблизиться к ее пониманию.
Перед тем как мы углубимся в детали, давайте разберем на примере различия между обычным контрактом, который задается на бумаге, и смарт-контрактом, который представлен в цифровом виде.
Как это работало до появления смарт-контрактов? Представьте группу лиц, которая желает установить некоторые правила и условия распределения ценностей, а также определенным механизмом гарантировать выполнение этого распределения по заданным правилам и условиям. Тогда они собирались вместе, составляли бумагу, на которой записывали свои идентификационные данные, условия, вовлеченные ценности, ставили дату и подписывались. Этот контракт также заверяла доверенная сторона, например нотариус. Далее, эти люди расходились в разные стороны со своей бумажной копией такого контракта и начинали выполнять какие-то действия, которые могли не соответствовать самому контракту, то есть они делали одно, а на бумаге заверено, что должны делать совершенно другое. И как выходить из этой ситуации? Фактически нужно кому-то из участников группы брать эту бумагу, брать какие-то доказательства, нести в суд и добиваться соответствия между контрактом и фактическими действиями. Довольно часто добиться справедливого выполнения этого контракта бывает сложно, что приводит к неприятным последствиям.
Что же можно сказать про смарт-контракты? Они объединяют в себе и возможность написания условий контракта, и механизм строгого их выполнения. Если условия были заданы и была подписана соответствующая транзакция или запрос, то после принятия этого запроса или транзакции уже невозможно изменить условия или повлиять на их выполнение.
Присутствует один валидатор или целая сеть, а также база данных, которая хранит все смарт-контракты, которые поступали на выполнение в строгой хронологической последовательности. Еще важно, что эта база данных должна содержать все условия-триггеры для выполнения смарт-контракта. Кроме того, она должна учитывать ту самую ценность, распределение которой описано в контракте. Если это касается некоторой цифровой валюты, значит эта база данных должна учитывать ее.
Иначе говоря, валидаторы смарт-контрактов должны иметь доступ ко всем данным, которыми оперирует смарт-контракт. Например, одна база данных должна использоваться для учета одновременно цифровых валют, балансов пользователей, транзакций пользователей и временных меток. Тогда в смарт-контракте условием может быть баланс пользователя в определенной валюте, наступление некоторого времени или факт осуществления некоторой транзакции, но не более того.
Вообще, сама терминология была придумана исследователем Nick Szabo и впервые применена в 1994 году, а задокументирована была в 1997 году в статье, которая описывает саму идею смарт-контрактов.
Смарт-контракты подразумевают, что выполняется некоторая автоматизация распределения ценности, которая может зависеть только от тех условий, которые заранее предустановлены. В самом простом варианте это выглядит, как контракт со строго заданными условиями, который подписан определенными сторонами.
Смарт-контракты призваны минимизировать доверие третьим сторонам. Иногда полностью исключается центр принятия решений, от которого все зависит. Кроме того, для таких контрактов проще проводить аудит. Это является следствием некоторых особенностей проектирования такой системы, но чаще всего мы понимаем под смарт-контрактом децентрализованную среду и наличие функций, позволяющих любому желающему проанализировать базу данных и провести полный аудит выполнения контрактов. Таким образом гарантируется защита от изменений данных задним числом, которые повлекут за собой изменения в выполнении самого контракта. Оцифровка большинства процессов при создании и запуске смарт-контракта часто упрощает технологию и стоимость их реализации.
Давайте рассмотрим очень простой пример. Он поможет приблизиться к пониманию функциональных возможностей смарт-контрактов, а также лучше ориентироваться, в каких случаях их стоит применять.
Его можно реализовать также с использованием Биткоина, хотя сейчас Биткоин еще сложно назвать полноценной платформой для смарт-контрактов. Итак, у нас есть некоторый покупатель и есть интернет-магазин. Покупатель хочет купить монитор в этом магазине. В самом простом случае покупатель оформляет и отправляет платеж, а интернет-магазин принимает его, подтверждает, после чего отправляет товар. Однако в этой ситуации присутствует необходимость большого доверия — покупатель должен на всю стоимость монитора доверять интернет-магазину. Поскольку интернет-магазин может иметь низкую репутацию в глазах покупателя, то существует риск, что по каким-то причинам после приема платежа магазин откажет в обслуживании и не отправит товар покупателю. Поэтому покупатель задается вопросом (соответственно, и интернет-магазин задается этим вопросом), что можно в этом случае применить, для того чтобы минимизировать такие риски и сделать более надежными подобные сделки.
В случае с Биткоином можно предоставить возможность покупателю и продавцу независимо друг от друга выбрать медиатора. Есть множество людей, которые занимаются решением спорных вопросов. И наши участники могут выбрать из общего списка медиаторов того, которому одновременно будут доверять. Вместе они создают multisignature адрес 2 из 3, где есть три ключа и необходимы две подписи любыми двумя ключами, чтобы потратить монеты с этого адреса. Один ключ будет принадлежать покупателю, второй — интернет-магазину, а третий — медиатору. И на такой multisignature адрес покупатель отправит сумму, необходимую для оплаты монитора. Теперь, когда продавец видит, что деньги на некоторое время заблокированы на multisignature адресе, который зависит от него, он смело может отправлять монитор почтой.
Далее, покупатель получает посылку, осматривает товар и принимает решение об окончательной покупке. Он может быть полностью согласен с предоставленным обслуживанием и подписать транзакцию своим ключом, где он передает монеты с multisignature адреса продавцу, а может быть чем-то недоволен. Во втором случае он связывается с медиатором для составления альтернативной транзакции, которая по-другому будет распределять эти монеты.
Допустим, монитор приехал немного поцарапанный и в комплекте не лежал кабель для подключения к компьютеру, хотя на сайте интернет-магазина было написано, что кабель должен входить в комплект. Тогда покупатель собирает доказательства, необходимые для того, чтобы доказать медиатору, что его обманули в этой ситуации: он делает скриншоты сайта, делает фотографию чека с почты, делает фотографию царапин на мониторе и показывает, что пломба была сорвана и кабель вытащили. Интернет-магазин в свою очередь собирает свои доказательства и передает их медиатору.
Медиатор заинтересован в том, чтобы удовлетворить одновременно и возмущение покупателя, и интересы интернет-магазина (дальше будет понятно, почему). Он составляет такую транзакцию, в которой монеты с multisignature адреса будут тратиться в некоторой пропорции между покупателем, интернет-магазином и медиатором, так как он берет себе часть в качестве вознаграждения за свою работу. Допустим, 90% всей суммы пойдет продавцу, 5% медиатору и 5% компенсации покупателю. Эту транзакцию медиатор подписывает своим ключом, но она еще не может быть применена, потому что для этого нужно две подписи, а стоит только одна. Такую транзакцию он отправляет и покупателю, и продавцу. Если хотя бы один из них будет удовлетворен таким вариантом перераспределения монет, то транзакция будет до-подписана и распространена в сеть. Для ее валидации достаточно, чтобы один из участников сделки согласился с вариантом медиатора.
При этом важно изначально выбрать медиатора так, чтобы оба участника доверяли ему. В таком случае он будет действовать независимо от интересов одного либо другого и объективно оценит ситуацию. Если же медиатор не предоставляет такой вариант распределения монет, который удовлетворит хотя бы одного участника, тогда, договорившись вместе, и покупатель, и интернет-магазин могут переправить монеты на новый multisignature адрес, поставив свои две подписи. Новый multisignature адрес будет составлен уже с другим медиатором, который, возможно, будет более компетентен в вопросе и предоставит лучший вариант.
Давайте рассмотрим более сложный пример, который отображает возможности смарт-контракта более явно.
Допустим, есть трое ребят, которые недавно заселились в одну комнату в общежитии. Они втроем заинтересованы в том, чтобы купить в свою комнату холодильник, которым они будут совместно пользоваться. Один из них вызвался собрать необходимую сумму для покупки холодильника и вести переговоры с продавцом. Однако они относительно недавно познакомились друг с другом и достаточного доверия между ними нет. Очевидно, что двое из них рискуют, отдавая деньги третьему. Кроме того, им нужно достичь согласия в выборе продавца.
Они могут воспользоваться escrow сервисом, то есть выбрать медиатора, который проконтролирует выполнение сделки и уладит спорные вопросы, если такие возникнут. Тогда, договорившись, они составляют смарт-контракт и прописывают в нем определенные условия.
Первое условие заключается в том, что до наступления определенного времени, допустим в течение одной недели, на соответствующий аккаунт смарт-контракта должны поступить три платежа с определенных адресов на определенную сумму. Если этого не происходит, смарт-контракт прекращает свое выполнение и возвращает монеты всем участникам. Если же условие выполняется, тогда задаются значения идентификаторов продавца и медиатора, а также проверяется условие, что все участники согласны с выбором продавца и медиатора. Когда все условия будут выполнены, то дальше средства будут переведены на указанные адреса. Подобный подход может обезопасить участников от мошенничества с любой стороны и вообще исключает необходимость доверять.
Мы видим на этом примере сам принцип, что такая возможность пошагово задавать параметры для выполнения каждого условия позволяет создавать системы любой сложности и глубины вложенных уровней. Кроме того, сначала в смарт-контракте можно определить первое условие, а только после его выполнения уже задавать параметры для следующего условия. Иначе говоря, формально условие прописывается, а параметры для него могут задаваться уже во время его работы.
Для классификации можно задавать разные группы критериев. Однако на данный момент развития технологий актуальными являются четыре из них.
Смарт-контракты можно отличать по среде выполнения, которая может быть либо централизованной, либо децентрализованной. В случае децентрализации мы имеем намного большую независимость и отказоустойчивость при выполнении смарт-контрактов.
Их также можно отличать по процессу задания и выполнения условий: они могут быть произвольно программируемые, ограниченные или предустановленные, т. е. строго типизированные. Когда на платформе смарт-контрактов существует только 4 определенных смарт-контракта, параметры к ним можно задавать произвольным образом. Соответственно, задавать их намного проще: мы выбираем контракт из списка и передаем параметры.
По способу инициирования существуют автоматизированные смарт-контракты, то есть при наступлении определенных условий они самоисполняются, а бывают такие контракты, в которых условия заданы, но платформа не проверяет автоматически их выполнение, для этого их нужно отдельно инициировать.
Кроме того, смарт-контракты различаются по уровню приватности. Они могут быть либо полностью открытые, либо частично, либо полностью конфиденциальные. Последнее значит, что сторонние наблюдатели не видят условия смарт-контрактов. Однако тема приватности очень обширная и ее лучше рассмотреть отдельно от текущей статьи.
Ниже мы подробнее остановимся на первых трех критериях, чтобы внести больше ясности в понимание текущей темы.
По среде выполнения различают централизованные и децентрализованные платформы смарт-контрактов. В случае централизованных цифровых контрактов используется один сервис, где существует только один валидатор и может быть служба резервного копирования и восстановления, которая так же централизованно управляется. Есть одна база данных, которая хранит всю необходимую информацию для задания условий смарт-контракта и распределения той ценности, которая учитывается в этой самой базе данных сервиса. У такого централизованного сервиса есть клиент, который определенными запросами задает условия и пользуется такими контрактами. Из-за того, что платформа централизованная, механизмы аутентификации могут быть менее надежными, чем в криптовалютах.
В качестве примера можно взять провайдеров мобильной связи (разных мобильных операторов). Допустим, определенный оператор ведет на своих серверах централизованным образом учет трафика, который может передаваться в разных форматах, например: в виде голосовых звонков, передачи SMS, трафика мобильного интернета, и по разным стандартам, а также ведет учет средств на балансах пользователей. Соответственно, провайдер мобильной связи может составлять контракты по учету предоставляемых услуг и их оплате с разными условиями. В таком случае легко задаются условия по типу “отправь SMS с таким-то кодом на такой-то номер и получишь такие-то условия распределения трафика”.
Можно еще один пример привести: традиционные банки с расширенной функциональностью интернет-банкинга и такие очень простые контракты, как регулярные платежи, автоматическая конвертация входящих платежей, автоматическое отчисление процента на указанный счет и т. п.
Если речь идет о смарт-контрактах с децентрализованной средой выполнения, тогда мы имеем группу валидаторов. В идеальном случае валидатором может стать вообще кто угодно. За счет протокола синхронизации базы данных и достижения консенсуса мы имеем некоторую общую базу данных, которая будет хранить теперь уже все транзакции со строго описанными контрактами, а не какие-то условные запросы, форматы которых часто меняются, а открытой спецификации нет. Здесь транзакции будут содержать инструкции по выполнению контракта в соответствии со строгой спецификацией. Эта спецификация открыта и, следовательно, сами пользователи платформы могут проводить аудит и валидировать смарт-контракты. Здесь мы видим, что децентрализованные платформы превосходят централизованные по независимости и отказоустойчивости, но их проектирование и обслуживание при этом гораздо сложнее.
Теперь разберем подробнее, как смарт-контракты могут отличаться по способу задания и выполнения условий. Здесь обратим внимание на смарт-контракты, которые программируются произвольно и полные по Тьюрингу. Полный по Тьюрингу смарт-контракт позволяет задавать практически любые алгоритмы в качестве условий выполнения контракта: прописывать циклы, какие-то функции расчета вероятностей и тому подобное — вплоть до своих собственных алгоритмов электронной подписи. В данном случае имеется в виду действительно произвольное написание логики.
Выделяют также произвольные смарт-контракты, но не полные по Тьюрингу. Сюда можно отнести Биткоин и Лайткоин со своим скриптом. Имеется в виду, что можно в произвольном порядке использовать только определенные операции, но уже нельзя написать циклы и собственные алгоритмы.
Кроме того, есть такие платформы смарт-контракта, которые реализуют заранее предустановленные смарт-контракты. К ним можно отнести Bitshares и Steemit. Bitshares имеет целый ряд смарт-контрактов для торговли, управления аккаунтами, управления самой платформой и ее параметрами. Steemit — похожая платформа, но она ориентирована уже не на выпуск токенов и торговлю, как Bitshares, а на ведение блогов, т. е. она хранит и обрабатывает контент децентрализованным образом.
К произвольным полным по Тьюрингу контрактам можно отнести платформу Ethereum и RootStock, которая еще находится на стадии разработки. Поэтому далее мы чуть детальнее остановимся на платформе смарт-контрактов Ethereum.
По способу инициации смарт-контракты тоже можно разделить минимум на две группы: автоматизированные и ручные (не автоматизированные). Для автоматизированных характерно, что при всех известных параметрах и наступивших условиях, смарт-контракт полностью выполняется автоматически, то есть не требует отправки каких-то дополнительных транзакций и траты дополнительной комиссии при каждом следующем выполнении. Сама платформа имеет все данные, для того чтобы рассчитать, каким образом смарт-контракт завершится. Логика там не произвольная, а заранее заданная и все это предсказуемо. То есть заранее можно оценить сложность выполнения смарт-контракта, использовать какую-то константную комиссию для него и все процессы по его выполнению проходят более эффективным образом.
Для смарт-контрактов, которые программируются произвольным образом, выполнение не автоматизировано. Для инициирования такого смарт-контракта фактически на каждом шаге нужно создавать новую транзакцию, которая будет вызывать уже следующий этап выполнения или следующий метод смарт-контракта, оплачивать соответствующую комиссию и дожидаться подтверждения транзакции. Выполнение может завершиться успешно или нет, потому что код смарт-контракта произвольный и могут появляться какие-то непредсказуемые моменты, такие как вечный цикл, нехватка каких-то параметров и аргументов, необработанные исключительные моменты и т. п.
Рассмотрим, какие могут быть аккаунты на платформе Ethereum. Здесь существует только два типа аккаунтов и больше никаких вариантов нет. Первый тип называется аккаунт пользователя, второй — аккаунт контракта. Разберемся, чем же они отличаются.
Аккаунт пользователя управляется только личным ключом электронной подписи. Владелец аккаунта генерирует свою пару ключей для электронной подписи по алгоритму ECDSA (Elliptic Curve Digital Signature Algorithm). Изменять состояние этого аккаунта могут только подписанные этим ключом транзакции.
Для аккаунта смарт-контракта предусмотрена отдельная логика. Он может управляться только с помощью заранее заданного программного кода, который полностью определяет поведение смарт-контракта: как он будет распоряжаться своими монетами при определенных обстоятельствах, по инициативе какого пользователя и при каких дополнительных условиях эти монеты будут распространяться. Если некоторые моменты не предусмотрены разработчиками в программном коде, могут возникнуть проблемы. Например, смарт-контракт может получить какое-то определенное состояние, при котором он не принимает инициирование дальнейшего выполнения ни от одного из пользователей. В таком случае монеты фактически окажутся замороженными, потому что смарт-контракт не предусматривает выхода из этого состояния.
В случае с аккаунтом пользователя, владелец самостоятельно генерирует пару ключей по ECDSA. Важно отметить, что Ethereum использует для электронной подписи точно такой же алгоритм и точно такую же эллиптическую кривую, как и Bitcoin, но адрес вычисляется несколько другим образом. Здесь уже не применяется результат двойного хеширования, как в Биткоине, а предусмотрено однократное хеширование функцией Keccak на длине 256 бит. От полученного значения отсекаются младшие биты, а именно 160 младших бит выходного значения хэш-функции. В итоге мы получаем адрес в Ethereum. Фактически он занимает 20 байт.
Обратим внимание, что идентификатор аккаунта в Ethereum кодируется в hex без применения контрольной суммы, в отличие от Bitcoin и многих других систем, где адрес кодируется в систему счисления по основанию 58 с добавлением контрольной суммы. Это значит, что работать с идентификаторами аккаунтов в Ethereum нужно осторожно: даже одна ошибка в идентификаторе гарантированно приведет к потере монет.
Есть важная особенность и она заключается в том, что аккаунт пользователя на уровне общей базы данных создается в тот момент, когда он принимает первый входящий платеж.
В отношении создания аккаунта смарт-контракта применяется совершенно другой подход. Изначально кто-то из пользователей пишет исходный код смарт-контракта, после чего код пропускается через специальный для платформы Ethereum компилятор, получая байт-код для собственной виртуальной машины Ethereum. Полученный байт-код помещается в специальное поле транзакции. Она заверяется от имени аккаунта инициатора. Далее, эта транзакция распространяется по сети и размещает код смарт-контракта. Комиссия за проведение транзакции и, соответственно, за выполнение контракта снимается с баланса аккаунта инициатора.
Каждый смарт-контракт обязательно содержит свой конструктор (этого контракта). Он может быть пустым, а может иметь содержимое. После того, как конструктор выполняется, создается идентификатор аккаунта смарт-контракта, используя который, можно отправлять монеты, вызывать определенные методы смарт-контракта и т. д.
Чтобы было понятнее, мы приступим к рассмотрению структуры транзакции Ethereum и примера кода смарт-контракта.
Транзакция Ethereum состоит из нескольких полей. Первое из них nonce — это некоторый порядковый номер транзакции относительно самого аккаунта, который ее распространяет и является ее автором. Это нужно для того, чтобы отличать двойники транзакций, то есть исключить случай, когда одна и та же транзакция принимается дважды. Благодаря применению идентификатора каждая транзакция имеет уникальное хеш-значение.
Далее следует такое поле, как gas price. Здесь указывается цена, по которой базовая валюта Ethereum конвертируется в gas, которым оплачивается выполнение смарт-контракта и выделение ресурса виртуальной машины. Что это значит?
В Биткоине комиссии оплачиваются непосредственно базовой валютой — самим биткоином. Это возможно благодаря простому механизм их расчета: мы оплачиваем строго объем данных, который содержится в транзакции. В Ethereum ситуация сложнее, потому что от объема данных транзакции отталкиваться очень сложно. Здесь транзакция еще может содержать программный код, который будет запускаться на виртуальной машине, а каждая операция виртуальной машины может иметь разную сложность. Существуют также операции, которые выделяют память для переменных. Они будут иметь свою сложность, от которой будет зависеть оплата за каждую операцию.
Стоимость каждой операции в эквиваленте gas будет константной. Он и вводится специально для того, чтобы определить константную стоимость каждой операции. В зависимости от нагрузки на сеть будет изменятся gas price, то есть коэффициент, согласно которому базовая валюта будет конвертироваться в эту вспомогательную единицу для оплаты комиссии.
Есть еще одна особенность транзакции в Ethereum: байт-код, который она содержит для выполнения в виртуальной машине, будет выполняться до тех пор, пока он не завершится с каким-то результатом (успех-неуспех) либо пока не закончится некоторое количество монет, выделенное на оплату комиссии. Именно во избежание ситуации, когда с аккаунта отправителя в случае какой-то ошибки потратились все монеты на комиссию (например, какой-то вечный цикл запустился в виртуальной машине), существует следующее поле — start gas (его часто называют gas limit) — оно определяет максимальный объем монет, которые отправитель готов потратить на выполнение определенной транзакции.
Следующее поле называется destination address. Сюда вписывается адрес получателя монет либо адрес конкретного смарт-контракта, методы которого будут вызываться. После него следует поле value, куда вписывается сумма монет, которые отправляются на destination address.
Далее располагается интересное поле под названием data, куда вписывается целая структура. Это не отдельное поле, а целая структура, в которой определяется код для виртуальной машины. Сюда можно помещать произвольные данные — для этого существуют отдельные правила.
И последнее поле называется signature. Оно одновременно содержит в себе и электронную подпись автора этой транзакции, и публичный ключ, которым будет проверяться эта подпись. Из публичного ключа можно получить идентификатор аккаунта отправителя этой транзакции, то есть уникально идентифицировать аккаунт отправителя в самой системе. По структуре транзакции основное мы выяснили.
Давайте сейчас рассмотрим детальнее самый простой смарт-контракт на примере.
Выше приведен упрощенный исходный код, который может удерживать монеты пользователей и возвращать их по требованию.
Итак, есть смарт-контракт Bank, который выполняет следующие функции: он накапливает на своем балансе монеты, то есть при подтверждении транзакции и размещении такого смарт-контракта создается новый аккаунт, который может содержать на своем балансе монеты; он запоминает пользователей и распределение монет между ними; имеет несколько методов управления балансами, то есть имеется возможность пополнения, вывода и проверки баланса пользователя.
Давайте пройдемся по каждой строке исходного кода. В этом контракте есть константные поля. Одно из них, с типом address, называется owner. Здесь контракт запоминает адрес пользователя, создавшего этот смарт-контракт. Далее, есть динамическая структура, которая сохраняет в себе соответствия между адресами пользователей и балансами.
После этого следует метод Bank — он называется так же, как и контракт. Соответственно, это его конструктор. Здесь происходит присвоение переменной owner адреса того, кто разместил этот смарт-контракт в сети. Это единственное, что происходит в этом конструкторе. То есть msg в данном случае — это именно те данные, которые были переданы виртуальной машине вместе с транзакцией, содержащей весь код этого контракта. Соответственно, msg.sender — это автор данной транзакции, которая размещает этот код. Он и будет владельцем смарт-контракта.
Метод deposit позволяет передать транзакцией определенное количество монет на аккаунт контракта. В данном случае смарт-контракт, получая эти монеты, оставляет их у себя на балансе, но в структуру balances записывает, кто именно был отправителем этих монет, чтобы знать, кому они принадлежат.
Следующий метод называется withdraw и он принимает один параметр — ту сумму монет, которую кто-то хочет вывести из этого банка. Здесь идет проверка, достаточно ли монет на балансе пользователя, который вызывает этот метод, чтобы их отправить. Если их достаточно, тогда сам смарт-контракт возвращает вызывающему это количество монет.
Далее идет метод проверки текущего баланса пользователя. Тот, кто вызывает этот метод, будет использоваться для получения этого баланса в смарт-контракте. Стоит отметить, что модификатор этого метода — view. Это означает, что сам метод никак не меняет переменные своего класса и он фактически является только методом чтения. Отдельная транзакция не создается для вызова этого метода, комиссия не платится, а все вычисления выполняются локально, после чего пользователь получает результат.
Метод kill нужен для того, чтобы уничтожить состояние смарт-контракта. И тут прописана дополнительная проверка, является ли вызывающий этого метода владельцем этого контракта. Если является, тогда контракт самоуничтожается, а функция уничтожения принимает один параметр — идентификатор аккаунта, на который контракт отправит все монеты, оставшиеся на его балансе. В данном случае оставшиеся монеты автоматически уйдут на адрес владельца контракта.
Рассмотрим схематично, как происходит выполнение таких смарт-контрактов на платформе Ethereum и как работает полный узел сети.
Полный узел сети Ethereum как минимум должен иметь четыре модуля.
Первым, как и для любого децентрализованного протокола, является P2P networking module — модуль сетевого соединения и работы с другими узлами, где идет обмен блоками, транзакциями, информацией о других узлах. Это традиционный компонент для всех децентрализованных криптовалют.
Далее, у нас есть модуль хранения данных блокчейна, обработки, выбора приоритетной ветки, дополнения блоков, отцепления блоков, проверки этих блоков и т. д.
Третий модуль называется EVM (Ethereum virtual machine) — это и есть виртуальная машина, которая принимает байт-код из Ethereum транзакции. Этот модуль принимает текущее состояние определенного аккаунта и выполняет изменения его состояния на базе полученного байт-кода. Версия виртуальной машины на каждом из узлов сети должна быть одинаковой. Вычисления происходят на каждом из узлов Ethereum абсолютно одинаковые, но они происходят в асинхронном порядке: кто-то раньше проверяет и принимает эту транзакцию, то есть выполняет весь содержащийся в ней код, а кто-то позже. Соответственно, при создании транзакции, она распространяется в сеть, узлы ее принимают и в момент верификации точно так же, как в Биткоине выполняется Bitcoin Script, здесь выполняется байт-код виртуальной машины.
Транзакция считается проверенной, если весь содержащийся в ней код был выполнен, было сгенерировано новое состояние определенного аккаунта и сохранено до тех пор, пока не будет понятно, применена эта транзакция либо нет. Если транзакция применена, тогда это состояние считается не только выполненным, но уже и актуальным. Есть база данных, которая хранит состояние каждого аккаунта для каждого узла сети. За счет того, что все вычисления происходят одинаково и состояние блокчейна одинаковое, то и база данных, содержащая состояния всех аккаунтов, тоже будет одинаковой для каждого узла.
Что касается ограничений, которые существуют для похожих на Ethereum платформ смарт-контрактов, то можно привести следующие:
Давайте рассмотрим те ограничения, которые накладываются на виртуальную машину, и, соответственно, развеем некоторые мифы о смарт-контрактах. На виртуальной машине, которая может быть не только в Ethereum, но и в подобных платформах, можно выполнять действительно произвольные логические операции, то есть написать код и он будет там выполняться, можно дополнительно выделять память. Однако комиссия оплачивается отдельно за каждую операцию и за каждую дополнительно выделенную единицу объема памяти.
Далее, виртуальная машина может читать данные из базы данных блокчейна, для того чтобы использовать эти данные в качестве триггера для выполнения той или иной логики смарт-контрактов. Виртуальная машина может создавать и отправлять транзакции, она может создавать новые контракты и вызывать методы других смарт-контрактов, которые уже опубликованы в сети: существуют, доступные и т. д.
Наиболее распространенный миф заключается в том, что смарт-контракты Ethereum могут использовать информацию из любых интернет-ресурсов в своих условиях. Правда состоит в том, что виртуальная машина не может отправить сетевой запрос какому-то внешнему информационному ресурсу в интернете, то есть нельзя написать такой смарт-контракт, который будет распределять ценность между пользователями в зависимости от того, допустим, какая погода на улице, либо кто выиграл в каком-то чемпионате, либо на основании того, какое еще происшествие случилось во внешнем мире, потому что информации об этих происшествиях просто нет в базе данных самой платформы. То есть в блокчейне ничего по этому поводу нет. Если оно там не появится, то и виртуальная машина не может использовать эти данные в качестве триггеров.
Давайте перечислим основные из них. Первый недостаток состоит в том, что существуют некоторые сложности при проектировании, разработке и тестировании смарт-контрактов в Ethereum (в Ethereum для написания смарт-контрактов используется язык Solidity). Действительно, практика показывает, что очень большой процент среди всех ошибок принадлежит человеческому фактору. Это фактически актуально и для уже написанных смарт-контрактов Ethereum, которые имеют сложность среднюю либо выше. Если для простых смарт-контрактов вероятность ошибки мала, то в сложных смарт-контрактах очень часто встречаются ошибки, которые приводят к хищению средств, к их заморозке, к уничтожению смарт-контрактов непредвиденным образом и т. п. Уже много таких случаев известно.
Второй недостаток заключается в том, что сама виртуальная машина не идеальна, так как она тоже написана людьми. Она может выполнять произвольные команды и в этом кроется уязвимость: можно определенным образом сконфигурировать ряд команд, которые приведут к непредвиденным заранее последствиям. Это очень сложная сфера, но существует уже несколько исследований, которые показывают, что эти уязвимости есть в текущей версии сети Ethereum и они могут привести к отказу работы многих смарт-контрактов.
Еще одна большая сложность, ее можно считать недостатком. Она заключается в том, что можно практическим либо техническим образом прийти к тому, что если скомпилировать байт-код контракта, который будет выполняться на виртуальной машине, можно определить некоторый специфический порядок операций. При выполнении в совокупности эти операции очень сильно нагрузят виртуальную машину и замедлят ее непропорционально той комиссии, которая была оплачена за выполнение этих операций.
В прошлом был уже такой период развития Ethereum, когда много ребят, которые разбирались детально в работе виртуальной машины, находили такие уязвимости. Фактически транзакции платили очень маленькую комиссию, но практически очень замедляли работу всей сети. Эти проблемы решаются очень сложно, так как нужно их, во-первых, детерминировать, во-вторых, скорректировать цену за выполнение этих операций и, в-третьих, провести хардфорк, что означает обновление всех узлов сети на новую версию программного обеспечения, а затем одновременную активировацию этих изменений.
Что касается Ethereum, то было проведено очень много исследований, получен очень большой практический опыт: как положительный, так и отрицательный, но тем не менее остаются сложности и уязвимости, с которыми предстоит еще как-то бороться.
Итак, тематическая часть статьи завершена, перейдем к вопросам, которые возникают достаточно часто.
— Если все стороны действующего смарт-контракта хотят изменить условия, могут ли они отменить этот смарт-контракт с помощью мультиподписи, а потом создать новый смарт-контракт с обновленными условиями его выполнения?
Тут ответ будет двоякий. Почему? Потому что с одной стороны смарт-контракт единожды задается и он уже не подразумевает никаких изменений, а с другой стороны он может иметь заранее прописанную логику, которая предусматривает полное или частичное изменение каких-то условий. То есть если вы хотите что-то поменять в своем смарт-контракте, то вы заранее должны прописать условия, по которым вы можете обновить эти условия. Соответственно, только таким предусмотрительным образом можно организовать обновление контракта. Но и здесь тоже можно напороться на неприятности: допустить какую-то ошибку и получить соответствующую уязвимость. Поэтому такие вещи нужно очень детально и тщательно проектировать и тестировать.
— А если медиатор войдет в сговор с одной из сторон-участников: escrow или смарт-контракта? Обязателен ли медиатор в смарт-контракте?
Медиатор не обязателен в смарт-контракте. Его может не быть. Если в случае escrow медиатор войдет в сговор с одной из сторон, то да, эта схема тогда резко теряет всю свою ценность. Поэтому медиаторы и выбираются таким образом, что им доверяют одновременно все стороны, вовлеченные в этот процесс. Соответственно, вы просто не будете переводить монеты на multisignature адрес с тем медиатором, которому не доверяете.
— Можно ли одной транзакцией Ethereum перевести много разных токенов со своего адреса на разные целевые адреса, например биржевые адреса, где торгуются эти токены?
Это хороший вопрос и он касается модели транзакций Ethereum и ее отличия от модели Bitcoin. И отличие это кардинально. Если в модели транзакции Ethereum вы просто переводите монеты, то они переводятся только с одного адреса на другой, без сдачи, просто конкретная сумма, которую вы указали. Иначе говоря, это не модель непотраченных выходов (UTXO), а модель именно аккаунтов и соответствующих балансов. Одной транзакцией отправить сразу несколько разных токенов теоретически можно, если написать хитрый смарт-контракт, но все равно придется сделать много транзакций, создать контракт, потом передать ему токены и монеты, а потом вызвать соответствующий метод. Это требует усилий и времени, соответственно, на практике это так не работает и все платежи в Ethereum совершаются отдельными транзакциями.
— Один из мифов о платформе Ethereum состоит в том, что невозможно описать такие условия, которые будут зависеть от данных внешнего интернет-ресурса, как же быть тогда?
Решение состоит в том, что сам смарт-контракт может предусматривать одного или нескольких так называемых доверенных оракулов, которые собирают данные о состоянии вещей во внешнем мире и передают их в смарт-контракты через специальные методы. Сам контракт считает правдой те данные, которые он получил от доверенных сторон. Для большей надежности просто выбирают большую группу оракулов и минимизируют риск их сговора. Сам контракт может не учитывать данные от оракулов, которые противоречат большинству.
Данной теме посвящена одна из лекций онлайн-курса по Blockchain — “Введение в смарт-контракты”.
Обычный контракт vs. смарт-контракт
Перед тем как мы углубимся в детали, давайте разберем на примере различия между обычным контрактом, который задается на бумаге, и смарт-контрактом, который представлен в цифровом виде.
Как это работало до появления смарт-контрактов? Представьте группу лиц, которая желает установить некоторые правила и условия распределения ценностей, а также определенным механизмом гарантировать выполнение этого распределения по заданным правилам и условиям. Тогда они собирались вместе, составляли бумагу, на которой записывали свои идентификационные данные, условия, вовлеченные ценности, ставили дату и подписывались. Этот контракт также заверяла доверенная сторона, например нотариус. Далее, эти люди расходились в разные стороны со своей бумажной копией такого контракта и начинали выполнять какие-то действия, которые могли не соответствовать самому контракту, то есть они делали одно, а на бумаге заверено, что должны делать совершенно другое. И как выходить из этой ситуации? Фактически нужно кому-то из участников группы брать эту бумагу, брать какие-то доказательства, нести в суд и добиваться соответствия между контрактом и фактическими действиями. Довольно часто добиться справедливого выполнения этого контракта бывает сложно, что приводит к неприятным последствиям.
Что же можно сказать про смарт-контракты? Они объединяют в себе и возможность написания условий контракта, и механизм строгого их выполнения. Если условия были заданы и была подписана соответствующая транзакция или запрос, то после принятия этого запроса или транзакции уже невозможно изменить условия или повлиять на их выполнение.
Присутствует один валидатор или целая сеть, а также база данных, которая хранит все смарт-контракты, которые поступали на выполнение в строгой хронологической последовательности. Еще важно, что эта база данных должна содержать все условия-триггеры для выполнения смарт-контракта. Кроме того, она должна учитывать ту самую ценность, распределение которой описано в контракте. Если это касается некоторой цифровой валюты, значит эта база данных должна учитывать ее.
Иначе говоря, валидаторы смарт-контрактов должны иметь доступ ко всем данным, которыми оперирует смарт-контракт. Например, одна база данных должна использоваться для учета одновременно цифровых валют, балансов пользователей, транзакций пользователей и временных меток. Тогда в смарт-контракте условием может быть баланс пользователя в определенной валюте, наступление некоторого времени или факт осуществления некоторой транзакции, но не более того.
Определение смарт-контракта
Вообще, сама терминология была придумана исследователем Nick Szabo и впервые применена в 1994 году, а задокументирована была в 1997 году в статье, которая описывает саму идею смарт-контрактов.
Смарт-контракты подразумевают, что выполняется некоторая автоматизация распределения ценности, которая может зависеть только от тех условий, которые заранее предустановлены. В самом простом варианте это выглядит, как контракт со строго заданными условиями, который подписан определенными сторонами.
Смарт-контракты призваны минимизировать доверие третьим сторонам. Иногда полностью исключается центр принятия решений, от которого все зависит. Кроме того, для таких контрактов проще проводить аудит. Это является следствием некоторых особенностей проектирования такой системы, но чаще всего мы понимаем под смарт-контрактом децентрализованную среду и наличие функций, позволяющих любому желающему проанализировать базу данных и провести полный аудит выполнения контрактов. Таким образом гарантируется защита от изменений данных задним числом, которые повлекут за собой изменения в выполнении самого контракта. Оцифровка большинства процессов при создании и запуске смарт-контракта часто упрощает технологию и стоимость их реализации.
Простой пример — Escrow сервис
Давайте рассмотрим очень простой пример. Он поможет приблизиться к пониманию функциональных возможностей смарт-контрактов, а также лучше ориентироваться, в каких случаях их стоит применять.
Его можно реализовать также с использованием Биткоина, хотя сейчас Биткоин еще сложно назвать полноценной платформой для смарт-контрактов. Итак, у нас есть некоторый покупатель и есть интернет-магазин. Покупатель хочет купить монитор в этом магазине. В самом простом случае покупатель оформляет и отправляет платеж, а интернет-магазин принимает его, подтверждает, после чего отправляет товар. Однако в этой ситуации присутствует необходимость большого доверия — покупатель должен на всю стоимость монитора доверять интернет-магазину. Поскольку интернет-магазин может иметь низкую репутацию в глазах покупателя, то существует риск, что по каким-то причинам после приема платежа магазин откажет в обслуживании и не отправит товар покупателю. Поэтому покупатель задается вопросом (соответственно, и интернет-магазин задается этим вопросом), что можно в этом случае применить, для того чтобы минимизировать такие риски и сделать более надежными подобные сделки.
В случае с Биткоином можно предоставить возможность покупателю и продавцу независимо друг от друга выбрать медиатора. Есть множество людей, которые занимаются решением спорных вопросов. И наши участники могут выбрать из общего списка медиаторов того, которому одновременно будут доверять. Вместе они создают multisignature адрес 2 из 3, где есть три ключа и необходимы две подписи любыми двумя ключами, чтобы потратить монеты с этого адреса. Один ключ будет принадлежать покупателю, второй — интернет-магазину, а третий — медиатору. И на такой multisignature адрес покупатель отправит сумму, необходимую для оплаты монитора. Теперь, когда продавец видит, что деньги на некоторое время заблокированы на multisignature адресе, который зависит от него, он смело может отправлять монитор почтой.
Далее, покупатель получает посылку, осматривает товар и принимает решение об окончательной покупке. Он может быть полностью согласен с предоставленным обслуживанием и подписать транзакцию своим ключом, где он передает монеты с multisignature адреса продавцу, а может быть чем-то недоволен. Во втором случае он связывается с медиатором для составления альтернативной транзакции, которая по-другому будет распределять эти монеты.
Допустим, монитор приехал немного поцарапанный и в комплекте не лежал кабель для подключения к компьютеру, хотя на сайте интернет-магазина было написано, что кабель должен входить в комплект. Тогда покупатель собирает доказательства, необходимые для того, чтобы доказать медиатору, что его обманули в этой ситуации: он делает скриншоты сайта, делает фотографию чека с почты, делает фотографию царапин на мониторе и показывает, что пломба была сорвана и кабель вытащили. Интернет-магазин в свою очередь собирает свои доказательства и передает их медиатору.
Медиатор заинтересован в том, чтобы удовлетворить одновременно и возмущение покупателя, и интересы интернет-магазина (дальше будет понятно, почему). Он составляет такую транзакцию, в которой монеты с multisignature адреса будут тратиться в некоторой пропорции между покупателем, интернет-магазином и медиатором, так как он берет себе часть в качестве вознаграждения за свою работу. Допустим, 90% всей суммы пойдет продавцу, 5% медиатору и 5% компенсации покупателю. Эту транзакцию медиатор подписывает своим ключом, но она еще не может быть применена, потому что для этого нужно две подписи, а стоит только одна. Такую транзакцию он отправляет и покупателю, и продавцу. Если хотя бы один из них будет удовлетворен таким вариантом перераспределения монет, то транзакция будет до-подписана и распространена в сеть. Для ее валидации достаточно, чтобы один из участников сделки согласился с вариантом медиатора.
При этом важно изначально выбрать медиатора так, чтобы оба участника доверяли ему. В таком случае он будет действовать независимо от интересов одного либо другого и объективно оценит ситуацию. Если же медиатор не предоставляет такой вариант распределения монет, который удовлетворит хотя бы одного участника, тогда, договорившись вместе, и покупатель, и интернет-магазин могут переправить монеты на новый multisignature адрес, поставив свои две подписи. Новый multisignature адрес будет составлен уже с другим медиатором, который, возможно, будет более компетентен в вопросе и предоставит лучший вариант.
Пример с общежитием и холодильником
Давайте рассмотрим более сложный пример, который отображает возможности смарт-контракта более явно.
Допустим, есть трое ребят, которые недавно заселились в одну комнату в общежитии. Они втроем заинтересованы в том, чтобы купить в свою комнату холодильник, которым они будут совместно пользоваться. Один из них вызвался собрать необходимую сумму для покупки холодильника и вести переговоры с продавцом. Однако они относительно недавно познакомились друг с другом и достаточного доверия между ними нет. Очевидно, что двое из них рискуют, отдавая деньги третьему. Кроме того, им нужно достичь согласия в выборе продавца.
Они могут воспользоваться escrow сервисом, то есть выбрать медиатора, который проконтролирует выполнение сделки и уладит спорные вопросы, если такие возникнут. Тогда, договорившись, они составляют смарт-контракт и прописывают в нем определенные условия.
Первое условие заключается в том, что до наступления определенного времени, допустим в течение одной недели, на соответствующий аккаунт смарт-контракта должны поступить три платежа с определенных адресов на определенную сумму. Если этого не происходит, смарт-контракт прекращает свое выполнение и возвращает монеты всем участникам. Если же условие выполняется, тогда задаются значения идентификаторов продавца и медиатора, а также проверяется условие, что все участники согласны с выбором продавца и медиатора. Когда все условия будут выполнены, то дальше средства будут переведены на указанные адреса. Подобный подход может обезопасить участников от мошенничества с любой стороны и вообще исключает необходимость доверять.
Мы видим на этом примере сам принцип, что такая возможность пошагово задавать параметры для выполнения каждого условия позволяет создавать системы любой сложности и глубины вложенных уровней. Кроме того, сначала в смарт-контракте можно определить первое условие, а только после его выполнения уже задавать параметры для следующего условия. Иначе говоря, формально условие прописывается, а параметры для него могут задаваться уже во время его работы.
Классификация смарт-контрактов
Для классификации можно задавать разные группы критериев. Однако на данный момент развития технологий актуальными являются четыре из них.
Смарт-контракты можно отличать по среде выполнения, которая может быть либо централизованной, либо децентрализованной. В случае децентрализации мы имеем намного большую независимость и отказоустойчивость при выполнении смарт-контрактов.
Их также можно отличать по процессу задания и выполнения условий: они могут быть произвольно программируемые, ограниченные или предустановленные, т. е. строго типизированные. Когда на платформе смарт-контрактов существует только 4 определенных смарт-контракта, параметры к ним можно задавать произвольным образом. Соответственно, задавать их намного проще: мы выбираем контракт из списка и передаем параметры.
По способу инициирования существуют автоматизированные смарт-контракты, то есть при наступлении определенных условий они самоисполняются, а бывают такие контракты, в которых условия заданы, но платформа не проверяет автоматически их выполнение, для этого их нужно отдельно инициировать.
Кроме того, смарт-контракты различаются по уровню приватности. Они могут быть либо полностью открытые, либо частично, либо полностью конфиденциальные. Последнее значит, что сторонние наблюдатели не видят условия смарт-контрактов. Однако тема приватности очень обширная и ее лучше рассмотреть отдельно от текущей статьи.
Ниже мы подробнее остановимся на первых трех критериях, чтобы внести больше ясности в понимание текущей темы.
Смарт-контракты по среде выполнения
По среде выполнения различают централизованные и децентрализованные платформы смарт-контрактов. В случае централизованных цифровых контрактов используется один сервис, где существует только один валидатор и может быть служба резервного копирования и восстановления, которая так же централизованно управляется. Есть одна база данных, которая хранит всю необходимую информацию для задания условий смарт-контракта и распределения той ценности, которая учитывается в этой самой базе данных сервиса. У такого централизованного сервиса есть клиент, который определенными запросами задает условия и пользуется такими контрактами. Из-за того, что платформа централизованная, механизмы аутентификации могут быть менее надежными, чем в криптовалютах.
В качестве примера можно взять провайдеров мобильной связи (разных мобильных операторов). Допустим, определенный оператор ведет на своих серверах централизованным образом учет трафика, который может передаваться в разных форматах, например: в виде голосовых звонков, передачи SMS, трафика мобильного интернета, и по разным стандартам, а также ведет учет средств на балансах пользователей. Соответственно, провайдер мобильной связи может составлять контракты по учету предоставляемых услуг и их оплате с разными условиями. В таком случае легко задаются условия по типу “отправь SMS с таким-то кодом на такой-то номер и получишь такие-то условия распределения трафика”.
Можно еще один пример привести: традиционные банки с расширенной функциональностью интернет-банкинга и такие очень простые контракты, как регулярные платежи, автоматическая конвертация входящих платежей, автоматическое отчисление процента на указанный счет и т. п.
Если речь идет о смарт-контрактах с децентрализованной средой выполнения, тогда мы имеем группу валидаторов. В идеальном случае валидатором может стать вообще кто угодно. За счет протокола синхронизации базы данных и достижения консенсуса мы имеем некоторую общую базу данных, которая будет хранить теперь уже все транзакции со строго описанными контрактами, а не какие-то условные запросы, форматы которых часто меняются, а открытой спецификации нет. Здесь транзакции будут содержать инструкции по выполнению контракта в соответствии со строгой спецификацией. Эта спецификация открыта и, следовательно, сами пользователи платформы могут проводить аудит и валидировать смарт-контракты. Здесь мы видим, что децентрализованные платформы превосходят централизованные по независимости и отказоустойчивости, но их проектирование и обслуживание при этом гораздо сложнее.
Смарт-контракты по способу задания и выполнения условий
Теперь разберем подробнее, как смарт-контракты могут отличаться по способу задания и выполнения условий. Здесь обратим внимание на смарт-контракты, которые программируются произвольно и полные по Тьюрингу. Полный по Тьюрингу смарт-контракт позволяет задавать практически любые алгоритмы в качестве условий выполнения контракта: прописывать циклы, какие-то функции расчета вероятностей и тому подобное — вплоть до своих собственных алгоритмов электронной подписи. В данном случае имеется в виду действительно произвольное написание логики.
Выделяют также произвольные смарт-контракты, но не полные по Тьюрингу. Сюда можно отнести Биткоин и Лайткоин со своим скриптом. Имеется в виду, что можно в произвольном порядке использовать только определенные операции, но уже нельзя написать циклы и собственные алгоритмы.
Кроме того, есть такие платформы смарт-контракта, которые реализуют заранее предустановленные смарт-контракты. К ним можно отнести Bitshares и Steemit. Bitshares имеет целый ряд смарт-контрактов для торговли, управления аккаунтами, управления самой платформой и ее параметрами. Steemit — похожая платформа, но она ориентирована уже не на выпуск токенов и торговлю, как Bitshares, а на ведение блогов, т. е. она хранит и обрабатывает контент децентрализованным образом.
К произвольным полным по Тьюрингу контрактам можно отнести платформу Ethereum и RootStock, которая еще находится на стадии разработки. Поэтому далее мы чуть детальнее остановимся на платформе смарт-контрактов Ethereum.
Смарт-контракты по способу инициации
По способу инициации смарт-контракты тоже можно разделить минимум на две группы: автоматизированные и ручные (не автоматизированные). Для автоматизированных характерно, что при всех известных параметрах и наступивших условиях, смарт-контракт полностью выполняется автоматически, то есть не требует отправки каких-то дополнительных транзакций и траты дополнительной комиссии при каждом следующем выполнении. Сама платформа имеет все данные, для того чтобы рассчитать, каким образом смарт-контракт завершится. Логика там не произвольная, а заранее заданная и все это предсказуемо. То есть заранее можно оценить сложность выполнения смарт-контракта, использовать какую-то константную комиссию для него и все процессы по его выполнению проходят более эффективным образом.
Для смарт-контрактов, которые программируются произвольным образом, выполнение не автоматизировано. Для инициирования такого смарт-контракта фактически на каждом шаге нужно создавать новую транзакцию, которая будет вызывать уже следующий этап выполнения или следующий метод смарт-контракта, оплачивать соответствующую комиссию и дожидаться подтверждения транзакции. Выполнение может завершиться успешно или нет, потому что код смарт-контракта произвольный и могут появляться какие-то непредсказуемые моменты, такие как вечный цикл, нехватка каких-то параметров и аргументов, необработанные исключительные моменты и т. п.
Аккаунты в Ethereum
Типы аккаунтов Ethereum
Рассмотрим, какие могут быть аккаунты на платформе Ethereum. Здесь существует только два типа аккаунтов и больше никаких вариантов нет. Первый тип называется аккаунт пользователя, второй — аккаунт контракта. Разберемся, чем же они отличаются.
Аккаунт пользователя управляется только личным ключом электронной подписи. Владелец аккаунта генерирует свою пару ключей для электронной подписи по алгоритму ECDSA (Elliptic Curve Digital Signature Algorithm). Изменять состояние этого аккаунта могут только подписанные этим ключом транзакции.
Для аккаунта смарт-контракта предусмотрена отдельная логика. Он может управляться только с помощью заранее заданного программного кода, который полностью определяет поведение смарт-контракта: как он будет распоряжаться своими монетами при определенных обстоятельствах, по инициативе какого пользователя и при каких дополнительных условиях эти монеты будут распространяться. Если некоторые моменты не предусмотрены разработчиками в программном коде, могут возникнуть проблемы. Например, смарт-контракт может получить какое-то определенное состояние, при котором он не принимает инициирование дальнейшего выполнения ни от одного из пользователей. В таком случае монеты фактически окажутся замороженными, потому что смарт-контракт не предусматривает выхода из этого состояния.
Как создаются аккаунты в Ethereum
В случае с аккаунтом пользователя, владелец самостоятельно генерирует пару ключей по ECDSA. Важно отметить, что Ethereum использует для электронной подписи точно такой же алгоритм и точно такую же эллиптическую кривую, как и Bitcoin, но адрес вычисляется несколько другим образом. Здесь уже не применяется результат двойного хеширования, как в Биткоине, а предусмотрено однократное хеширование функцией Keccak на длине 256 бит. От полученного значения отсекаются младшие биты, а именно 160 младших бит выходного значения хэш-функции. В итоге мы получаем адрес в Ethereum. Фактически он занимает 20 байт.
Обратим внимание, что идентификатор аккаунта в Ethereum кодируется в hex без применения контрольной суммы, в отличие от Bitcoin и многих других систем, где адрес кодируется в систему счисления по основанию 58 с добавлением контрольной суммы. Это значит, что работать с идентификаторами аккаунтов в Ethereum нужно осторожно: даже одна ошибка в идентификаторе гарантированно приведет к потере монет.
Есть важная особенность и она заключается в том, что аккаунт пользователя на уровне общей базы данных создается в тот момент, когда он принимает первый входящий платеж.
В отношении создания аккаунта смарт-контракта применяется совершенно другой подход. Изначально кто-то из пользователей пишет исходный код смарт-контракта, после чего код пропускается через специальный для платформы Ethereum компилятор, получая байт-код для собственной виртуальной машины Ethereum. Полученный байт-код помещается в специальное поле транзакции. Она заверяется от имени аккаунта инициатора. Далее, эта транзакция распространяется по сети и размещает код смарт-контракта. Комиссия за проведение транзакции и, соответственно, за выполнение контракта снимается с баланса аккаунта инициатора.
Каждый смарт-контракт обязательно содержит свой конструктор (этого контракта). Он может быть пустым, а может иметь содержимое. После того, как конструктор выполняется, создается идентификатор аккаунта смарт-контракта, используя который, можно отправлять монеты, вызывать определенные методы смарт-контракта и т. д.
Структура транзакции Ethereum
Чтобы было понятнее, мы приступим к рассмотрению структуры транзакции Ethereum и примера кода смарт-контракта.
Транзакция Ethereum состоит из нескольких полей. Первое из них nonce — это некоторый порядковый номер транзакции относительно самого аккаунта, который ее распространяет и является ее автором. Это нужно для того, чтобы отличать двойники транзакций, то есть исключить случай, когда одна и та же транзакция принимается дважды. Благодаря применению идентификатора каждая транзакция имеет уникальное хеш-значение.
Далее следует такое поле, как gas price. Здесь указывается цена, по которой базовая валюта Ethereum конвертируется в gas, которым оплачивается выполнение смарт-контракта и выделение ресурса виртуальной машины. Что это значит?
В Биткоине комиссии оплачиваются непосредственно базовой валютой — самим биткоином. Это возможно благодаря простому механизм их расчета: мы оплачиваем строго объем данных, который содержится в транзакции. В Ethereum ситуация сложнее, потому что от объема данных транзакции отталкиваться очень сложно. Здесь транзакция еще может содержать программный код, который будет запускаться на виртуальной машине, а каждая операция виртуальной машины может иметь разную сложность. Существуют также операции, которые выделяют память для переменных. Они будут иметь свою сложность, от которой будет зависеть оплата за каждую операцию.
Стоимость каждой операции в эквиваленте gas будет константной. Он и вводится специально для того, чтобы определить константную стоимость каждой операции. В зависимости от нагрузки на сеть будет изменятся gas price, то есть коэффициент, согласно которому базовая валюта будет конвертироваться в эту вспомогательную единицу для оплаты комиссии.
Есть еще одна особенность транзакции в Ethereum: байт-код, который она содержит для выполнения в виртуальной машине, будет выполняться до тех пор, пока он не завершится с каким-то результатом (успех-неуспех) либо пока не закончится некоторое количество монет, выделенное на оплату комиссии. Именно во избежание ситуации, когда с аккаунта отправителя в случае какой-то ошибки потратились все монеты на комиссию (например, какой-то вечный цикл запустился в виртуальной машине), существует следующее поле — start gas (его часто называют gas limit) — оно определяет максимальный объем монет, которые отправитель готов потратить на выполнение определенной транзакции.
Следующее поле называется destination address. Сюда вписывается адрес получателя монет либо адрес конкретного смарт-контракта, методы которого будут вызываться. После него следует поле value, куда вписывается сумма монет, которые отправляются на destination address.
Далее располагается интересное поле под названием data, куда вписывается целая структура. Это не отдельное поле, а целая структура, в которой определяется код для виртуальной машины. Сюда можно помещать произвольные данные — для этого существуют отдельные правила.
И последнее поле называется signature. Оно одновременно содержит в себе и электронную подпись автора этой транзакции, и публичный ключ, которым будет проверяться эта подпись. Из публичного ключа можно получить идентификатор аккаунта отправителя этой транзакции, то есть уникально идентифицировать аккаунт отправителя в самой системе. По структуре транзакции основное мы выяснили.
Пример кода смарт-контракта на Solidity
Давайте сейчас рассмотрим детальнее самый простой смарт-контракт на примере.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Выше приведен упрощенный исходный код, который может удерживать монеты пользователей и возвращать их по требованию.
Итак, есть смарт-контракт Bank, который выполняет следующие функции: он накапливает на своем балансе монеты, то есть при подтверждении транзакции и размещении такого смарт-контракта создается новый аккаунт, который может содержать на своем балансе монеты; он запоминает пользователей и распределение монет между ними; имеет несколько методов управления балансами, то есть имеется возможность пополнения, вывода и проверки баланса пользователя.
Давайте пройдемся по каждой строке исходного кода. В этом контракте есть константные поля. Одно из них, с типом address, называется owner. Здесь контракт запоминает адрес пользователя, создавшего этот смарт-контракт. Далее, есть динамическая структура, которая сохраняет в себе соответствия между адресами пользователей и балансами.
После этого следует метод Bank — он называется так же, как и контракт. Соответственно, это его конструктор. Здесь происходит присвоение переменной owner адреса того, кто разместил этот смарт-контракт в сети. Это единственное, что происходит в этом конструкторе. То есть msg в данном случае — это именно те данные, которые были переданы виртуальной машине вместе с транзакцией, содержащей весь код этого контракта. Соответственно, msg.sender — это автор данной транзакции, которая размещает этот код. Он и будет владельцем смарт-контракта.
Метод deposit позволяет передать транзакцией определенное количество монет на аккаунт контракта. В данном случае смарт-контракт, получая эти монеты, оставляет их у себя на балансе, но в структуру balances записывает, кто именно был отправителем этих монет, чтобы знать, кому они принадлежат.
Следующий метод называется withdraw и он принимает один параметр — ту сумму монет, которую кто-то хочет вывести из этого банка. Здесь идет проверка, достаточно ли монет на балансе пользователя, который вызывает этот метод, чтобы их отправить. Если их достаточно, тогда сам смарт-контракт возвращает вызывающему это количество монет.
Далее идет метод проверки текущего баланса пользователя. Тот, кто вызывает этот метод, будет использоваться для получения этого баланса в смарт-контракте. Стоит отметить, что модификатор этого метода — view. Это означает, что сам метод никак не меняет переменные своего класса и он фактически является только методом чтения. Отдельная транзакция не создается для вызова этого метода, комиссия не платится, а все вычисления выполняются локально, после чего пользователь получает результат.
Метод kill нужен для того, чтобы уничтожить состояние смарт-контракта. И тут прописана дополнительная проверка, является ли вызывающий этого метода владельцем этого контракта. Если является, тогда контракт самоуничтожается, а функция уничтожения принимает один параметр — идентификатор аккаунта, на который контракт отправит все монеты, оставшиеся на его балансе. В данном случае оставшиеся монеты автоматически уйдут на адрес владельца контракта.
Как работает полный узел сети Ethereum?
Рассмотрим схематично, как происходит выполнение таких смарт-контрактов на платформе Ethereum и как работает полный узел сети.
Полный узел сети Ethereum как минимум должен иметь четыре модуля.
Первым, как и для любого децентрализованного протокола, является P2P networking module — модуль сетевого соединения и работы с другими узлами, где идет обмен блоками, транзакциями, информацией о других узлах. Это традиционный компонент для всех децентрализованных криптовалют.
Далее, у нас есть модуль хранения данных блокчейна, обработки, выбора приоритетной ветки, дополнения блоков, отцепления блоков, проверки этих блоков и т. д.
Третий модуль называется EVM (Ethereum virtual machine) — это и есть виртуальная машина, которая принимает байт-код из Ethereum транзакции. Этот модуль принимает текущее состояние определенного аккаунта и выполняет изменения его состояния на базе полученного байт-кода. Версия виртуальной машины на каждом из узлов сети должна быть одинаковой. Вычисления происходят на каждом из узлов Ethereum абсолютно одинаковые, но они происходят в асинхронном порядке: кто-то раньше проверяет и принимает эту транзакцию, то есть выполняет весь содержащийся в ней код, а кто-то позже. Соответственно, при создании транзакции, она распространяется в сеть, узлы ее принимают и в момент верификации точно так же, как в Биткоине выполняется Bitcoin Script, здесь выполняется байт-код виртуальной машины.
Транзакция считается проверенной, если весь содержащийся в ней код был выполнен, было сгенерировано новое состояние определенного аккаунта и сохранено до тех пор, пока не будет понятно, применена эта транзакция либо нет. Если транзакция применена, тогда это состояние считается не только выполненным, но уже и актуальным. Есть база данных, которая хранит состояние каждого аккаунта для каждого узла сети. За счет того, что все вычисления происходят одинаково и состояние блокчейна одинаковое, то и база данных, содержащая состояния всех аккаунтов, тоже будет одинаковой для каждого узла.
Мифы и ограничения смарт-контрактов
Что касается ограничений, которые существуют для похожих на Ethereum платформ смарт-контрактов, то можно привести следующие:
- code execution;
- allocate memory;
- blockchain data;
- send payments;
- create new contract;
- call other contracts.
Давайте рассмотрим те ограничения, которые накладываются на виртуальную машину, и, соответственно, развеем некоторые мифы о смарт-контрактах. На виртуальной машине, которая может быть не только в Ethereum, но и в подобных платформах, можно выполнять действительно произвольные логические операции, то есть написать код и он будет там выполняться, можно дополнительно выделять память. Однако комиссия оплачивается отдельно за каждую операцию и за каждую дополнительно выделенную единицу объема памяти.
Далее, виртуальная машина может читать данные из базы данных блокчейна, для того чтобы использовать эти данные в качестве триггера для выполнения той или иной логики смарт-контрактов. Виртуальная машина может создавать и отправлять транзакции, она может создавать новые контракты и вызывать методы других смарт-контрактов, которые уже опубликованы в сети: существуют, доступные и т. д.
Наиболее распространенный миф заключается в том, что смарт-контракты Ethereum могут использовать информацию из любых интернет-ресурсов в своих условиях. Правда состоит в том, что виртуальная машина не может отправить сетевой запрос какому-то внешнему информационному ресурсу в интернете, то есть нельзя написать такой смарт-контракт, который будет распределять ценность между пользователями в зависимости от того, допустим, какая погода на улице, либо кто выиграл в каком-то чемпионате, либо на основании того, какое еще происшествие случилось во внешнем мире, потому что информации об этих происшествиях просто нет в базе данных самой платформы. То есть в блокчейне ничего по этому поводу нет. Если оно там не появится, то и виртуальная машина не может использовать эти данные в качестве триггеров.
Недостатки Ethereum
Давайте перечислим основные из них. Первый недостаток состоит в том, что существуют некоторые сложности при проектировании, разработке и тестировании смарт-контрактов в Ethereum (в Ethereum для написания смарт-контрактов используется язык Solidity). Действительно, практика показывает, что очень большой процент среди всех ошибок принадлежит человеческому фактору. Это фактически актуально и для уже написанных смарт-контрактов Ethereum, которые имеют сложность среднюю либо выше. Если для простых смарт-контрактов вероятность ошибки мала, то в сложных смарт-контрактах очень часто встречаются ошибки, которые приводят к хищению средств, к их заморозке, к уничтожению смарт-контрактов непредвиденным образом и т. п. Уже много таких случаев известно.
Второй недостаток заключается в том, что сама виртуальная машина не идеальна, так как она тоже написана людьми. Она может выполнять произвольные команды и в этом кроется уязвимость: можно определенным образом сконфигурировать ряд команд, которые приведут к непредвиденным заранее последствиям. Это очень сложная сфера, но существует уже несколько исследований, которые показывают, что эти уязвимости есть в текущей версии сети Ethereum и они могут привести к отказу работы многих смарт-контрактов.
Еще одна большая сложность, ее можно считать недостатком. Она заключается в том, что можно практическим либо техническим образом прийти к тому, что если скомпилировать байт-код контракта, который будет выполняться на виртуальной машине, можно определить некоторый специфический порядок операций. При выполнении в совокупности эти операции очень сильно нагрузят виртуальную машину и замедлят ее непропорционально той комиссии, которая была оплачена за выполнение этих операций.
В прошлом был уже такой период развития Ethereum, когда много ребят, которые разбирались детально в работе виртуальной машины, находили такие уязвимости. Фактически транзакции платили очень маленькую комиссию, но практически очень замедляли работу всей сети. Эти проблемы решаются очень сложно, так как нужно их, во-первых, детерминировать, во-вторых, скорректировать цену за выполнение этих операций и, в-третьих, провести хардфорк, что означает обновление всех узлов сети на новую версию программного обеспечения, а затем одновременную активировацию этих изменений.
Что касается Ethereum, то было проведено очень много исследований, получен очень большой практический опыт: как положительный, так и отрицательный, но тем не менее остаются сложности и уязвимости, с которыми предстоит еще как-то бороться.
Итак, тематическая часть статьи завершена, перейдем к вопросам, которые возникают достаточно часто.
Часто задаваемые вопросы
— Если все стороны действующего смарт-контракта хотят изменить условия, могут ли они отменить этот смарт-контракт с помощью мультиподписи, а потом создать новый смарт-контракт с обновленными условиями его выполнения?
Тут ответ будет двоякий. Почему? Потому что с одной стороны смарт-контракт единожды задается и он уже не подразумевает никаких изменений, а с другой стороны он может иметь заранее прописанную логику, которая предусматривает полное или частичное изменение каких-то условий. То есть если вы хотите что-то поменять в своем смарт-контракте, то вы заранее должны прописать условия, по которым вы можете обновить эти условия. Соответственно, только таким предусмотрительным образом можно организовать обновление контракта. Но и здесь тоже можно напороться на неприятности: допустить какую-то ошибку и получить соответствующую уязвимость. Поэтому такие вещи нужно очень детально и тщательно проектировать и тестировать.
— А если медиатор войдет в сговор с одной из сторон-участников: escrow или смарт-контракта? Обязателен ли медиатор в смарт-контракте?
Медиатор не обязателен в смарт-контракте. Его может не быть. Если в случае escrow медиатор войдет в сговор с одной из сторон, то да, эта схема тогда резко теряет всю свою ценность. Поэтому медиаторы и выбираются таким образом, что им доверяют одновременно все стороны, вовлеченные в этот процесс. Соответственно, вы просто не будете переводить монеты на multisignature адрес с тем медиатором, которому не доверяете.
— Можно ли одной транзакцией Ethereum перевести много разных токенов со своего адреса на разные целевые адреса, например биржевые адреса, где торгуются эти токены?
Это хороший вопрос и он касается модели транзакций Ethereum и ее отличия от модели Bitcoin. И отличие это кардинально. Если в модели транзакции Ethereum вы просто переводите монеты, то они переводятся только с одного адреса на другой, без сдачи, просто конкретная сумма, которую вы указали. Иначе говоря, это не модель непотраченных выходов (UTXO), а модель именно аккаунтов и соответствующих балансов. Одной транзакцией отправить сразу несколько разных токенов теоретически можно, если написать хитрый смарт-контракт, но все равно придется сделать много транзакций, создать контракт, потом передать ему токены и монеты, а потом вызвать соответствующий метод. Это требует усилий и времени, соответственно, на практике это так не работает и все платежи в Ethereum совершаются отдельными транзакциями.
— Один из мифов о платформе Ethereum состоит в том, что невозможно описать такие условия, которые будут зависеть от данных внешнего интернет-ресурса, как же быть тогда?
Решение состоит в том, что сам смарт-контракт может предусматривать одного или нескольких так называемых доверенных оракулов, которые собирают данные о состоянии вещей во внешнем мире и передают их в смарт-контракты через специальные методы. Сам контракт считает правдой те данные, которые он получил от доверенных сторон. Для большей надежности просто выбирают большую группу оракулов и минимизируют риск их сговора. Сам контракт может не учитывать данные от оракулов, которые противоречат большинству.
Данной теме посвящена одна из лекций онлайн-курса по Blockchain — “Введение в смарт-контракты”.
