Smart contracts что это
Как умные контракты изменят нашу жизнь
Что такое умные контракты, как они работают и почему будущее именно за ними.
Блокчейн представляет собой децентрализованную систему, существующую благодаря множеству объединенных в сеть компьютеров. Поэтому одно из его главных достоинств — то, что вы можете не платить посредникам и экономить свое время и нервы.
У блокчейна есть свои недостатки, но он быстрее, надежнее и безопаснее традиционных систем, и поэтому банки и правительственные организации все чаще используют эту технологию для своих нужд.
В 1994 году Ник Сабо, специалист в области права и криптограф, понял, что с помощью децентрализованного реестра можно заключать «умные контракты», которые также называют самоисполняемыми, цифровыми или смарт-контрактами.
Такие контракты могут быть записаны в виде кода, сохранены и продублированы в системе, а их выполнение обеспечит сеть компьютеров, управляющая блокчейном. Также с помощью реестра можно будет переводить друг другу деньги и получать товары или услуги.
Что такое умные контракты?
Умные контракты позволяют обмениваться деньгами, собственностью, акциями или другими активами, не прибегая к услугам посредников.
Для того, чтобы заключить обычную сделку, нужно пойти к юристу или нотариусу, заплатить и дождаться оформления документов. Умные контракты работают как торговые автоматы: вы просто бросаете в автомат (то есть в реестр) биткоин, и хранившийся у третьего лица контракт, водительские права или любая другая услуга, которую вы заказывали, падает на ваш счет.
Кроме того, в отличие от традиционных соглашений, умные контракты не только содержат информацию об обязательствах сторон и штрафах за их нарушение, но и сами автоматически обеспечивают выполнение всех условий договора.
На недавнем блокчейн-саммите в Вашингтоне Виталик Бутерин, 23-летний программист из проекта Ethereum, объяснил, что в умном контракте актив или валюта переводятся в программу, которая следит за соблюдением заложенного набора условий.
В определенный момент эта программа подтверждает выполнение условия контракта и автоматически определяет, должен ли указанный актив перейти к одному из участников сделки или немедленно вернуться к другому участнику (а может быть, условия несколько сложнее). Все это время документ хранится и дублируется в децентрализованном реестре, что обеспечивает его надежность и не позволяет ни одной из сторон менять условия соглашения.
Пример умного контракта
Вот код, написанный для обычного умного контракта на блокчейн-платформе Ethereum. Контракты могут быть написаны в любом блокчейне, но Ethereum наиболее популярен, поскольку предоставляет неограниченные возможности для написания умных контрактов и работы с ними.
Образец умного контракта, написанного на платформе Ethereum. Источник: www.ethereum.org/token
Здесь говорится, что создатель контракта должен получить 10 тыс. биткоинов. Этот контракт позволяет любому, у кого достаточно средств на счете, перевести биткоины другим людям.
Практическое применение умных контрактов
Используя умные контракты, можно упростить работу во многих сферах жизни, в том числе логистике, менеджменте, юриспруденции и даже в выборах.
По мнению экспертов, сфальсифицировать итоги выборов практически нереально, однако благодаря умным контрактам можно полностью исключить возможность внешнего вмешательства в систему голосования.
В таком случае голоса избирателей будут помещены в распределенный реестр, и для их декодирования потребуется исключительные вычислительные возможности. Таких компьютеров не существует, так что взломать эту систему будет невозможно.
Блокчейн не только предлагает надежный и прозрачный общий реестр, но и помогает избежать недопонимания при совместной работе или ситуаций, когда стороны составляют контракты независимо друг от друга.
Логистика и снабжение
Разработчик протокола Bitcoin Core Джефф Гарзик говорит:
«UPS может исполнять контракты, в которых будет сказано: “Если мы получим оплату за доставку товара, то его производитель, который в цепочке поставок находится на много звеньев выше, немедленно начнет создавать новый такой товар, поскольку этот уже доставлен по назначению”».
Снабжение слишком часто страдает из-за бюрократии, когда разные формы должны пройти утверждение в многочисленных инстанциях. Из-за этого мошенники получают возможность заработать, а компании несут убытки. Блокчейн позволяет избежать этих проблем, так как каждый участник цепочки поставок получает доступ к безопасной электронной системе, которая контролирует выполнение работ и платежи.
Так, банк Barclays Corporate Bank использует умные контракты для того, чтобы регистрировать переход права собственности и автоматически перечислять платежи в другие кредитно-финансовые учреждения.
Задумайтесь о будущем, где все будет автоматизировано. Google уже строит его, создавая умные телефоны, умные очки и даже умные автомобили. И здесь на помощь придут умные контракты.
Возьмем, например, самоуправляемые или самопаркующиеся автомобили. Умные контракты будут определять, кто виновен в аварии: датчик или водитель, а также помогут при разрешении любых других ситуаций. С помощью умных контрактов страховые компании могут устанавливать размер взносов в зависимости от того, где и при каких условиях водители управляют транспортными средствами.
Другие индустрии, такие как эквайринг, кредитование и бухгалтерский учет, тоже будут использовать умные контракты — например, для оценки рисков и аудита в режиме реального времени. Юристы смогут перейти от составления традиционных контрактов к созданию типовых образцов умных контрактов. А на сайте Blockchain Technologies умные контракты превратились в электронно-бумажный гибрид: они подтверждаются блокчейном и получают материальное воплощение в виде бумажной копии.
Патрик Хаббард, главный специалист и старший управляющий маркетингом продуктов в SolarWinds:
«Янгонская фондовая биржа в Мьянме производит платежи с помощью распределенного реестра. Особый интерес вызывают те функции блокчейна, которые выходят за рамки традиционного использования технологии. Так на Янгонской бирже удалось решить проблему производимых в разное время расчетов в торговой системе, которая синхронизирует торги всего лишь дважды в день. Благодаря тому, что умные контракты сами обеспечивают исполнение сделок, блокчейны с их надежной системой проведения транзакций могут использоваться в ситуациях, где требуется выполнение сложных операций, зависящих от разных изменяющихся факторов. Вот почему Amazon, Microsoft Azure и IBM Bluemix уделяют такое внимание разработке облачной технологии “блокчейн как услуга”».
Минусы умных контрактов
Умные контракты далеки от совершенства. Что если в код попадут ошибки? Как должно регулировать эти контракты государство? И как оно будет взимать налоги с таких транзакций?
Список возможных проблем этим не ограничивается. Специалисты пытаются решить все вопросы, но подобные трудности отталкивают многих возможных пользователей.
Блокчейны, где можно заключить умные контракты
Bitcoin: Отличный блокчейн для транзакций с биткоинами, но возможности для работы с документами там ограничены.
Side Chains: Другое название для блокчейнов, параллельных Bitcoin, которые предоставляют несколько большие возможности для работы с контрактами.
NXT: Это открытая блокчейн-платформа с ограниченным числом образцов умных контрактов. Вы можете использовать только то, что там есть; написать свой код нельзя.
Ethereum: Открытая блокчейн-платформа, которая лучше всего подходит для написания умных контрактов и работы с ними. Вы можете составить любую программу, однако за вычислительные ресурсы платформы надо будет заплатить монетами ETH.
Автономность и безопасность. Как работают смарт-контракты
Смарт-контракт — компьютерная программа, которая выполняет соглашения, заключенные между двумя и более сторонами, в результате которых, при выполнении тех или иных условий происходят определенные действия. То есть, когда задействуется ранее запрограммированное условие, смарт-контракт автоматический выполняет соответствующее соглашение. Если рассматривать обычный контракт и смарт-контракт, то можно точно сказать, что они оба являются соглашениями, в которых две или более стороны соглашаются соблюдать ряд условий. Их фундаментальные элементы одинаковы: добровольное согласие всех сторон, объект договора (товара или услуги) и единая цель. Тем не менее, оба отличаются по трем факторам: способ написания, его юридические последствия и концепт соблюдения.
История смарт-контрактов
Термин «умные контракты» был придуман ученым-программистом Ником Сабо, вероятно, в 1993 году, чтобы объяснить цель внедрения в разработку протоколов того, что он назвал «высокоразвитой» ступенью договорного права и связанных с ними бизнес-практик в электронной коммерции. Сабо, вдохновленный такими исследователями, как Дэвид Чаум, также полагал, что разработка умных-контрактов с помощью выполнения криптографических протоколов и других механизмов цифровой безопасности могут стать значительным улучшением по сравнению с традиционными юридическими контрактами.
Сабо использовал слово «умный» в кавычках и заявил о том, что искусственный интеллект задействован не будет. Он приводил классический пример смарт-контракта: это вендинговый автомат. Если условия «контракта» устраивают покупателя (т. е. он опускает деньги в автомат), то машина автоматически соблюдает условия неписаного соглашения и предоставляет покупку.
В настоящее время было разработано несколько формальных языков, которые были предложены для определения условий договора. На данный момент есть много рабочих групп, специализирующиеся на смарт-контрактах, которые содействуют продолжению этого исследования в будущем. До появления блокчейна не было платформы, которая могла бы сделать смарт-контракты реальностью, поэтому она была определена только концептуально.
Как работают смарт-контракты?
Умные контракты полностью цифровые и написаны на языке программирования. В дополнение к установлению обязательств и последствий таким же образом, как и в обычном физическом документе, код может выполняться автоматически. Следовательно, он может получать и обрабатывать информацию, касающуюся переговоров, уже принимая меры в соответствии с правилами договора. BTC ограничен в использовании токенов для финансовых переводов.
Платформа Ethereum заменяет более ограниченный язык BTC (язык сценариев, насчитывающий около ста) языком, который позволяет разработчикам задавать собственные сценарии. Ethereum позволяет разработчикам программировать свои собственные смарт-контракты. Язык является «полным по Тьюрингу», что означает, что он поддерживает более широкий инструментарий вычислительных инструкций.
Платформа Ethereum использовалась для распространения децентрализованных приложений (DApps). Вместо множества приложений, управляемых многими протоколами, Ethereum позволяет управлять всеми приложениями по одному протоколу.
Ethereum — это платформа, которая позволяет разработчикам создавать любую программу, и запускать ее на основных функциях блокчейна, используя смарт-контракты для автоматического выполнения своих действий, задействуя предопределенные условия, встроенные в алгоритм. В случае, если условия будут выполнены, заданная функция автоматически завершается без необходимости предпринятия каких-либо действий.
Преимущества смарт-контрактов
Используя смарт-контракты, больше нет необходимости прибегать к помощи третьей стороны, например, адвоката или нотариуса, который, помимо возможных ошибок, влечет за собой значительные расходы. Блокчейн способен защитить информацию в зашифрованной сети, к которой можно обращаться из любой точки мира, поэтому скорость и безопасность очевидны. Самыми главными преимуществами контрактов являются:
Автономность
Эти контракты всегда заключаются между одним или несколькими физическими или юридическими лицами, но без посредников. Для подтверждения договора не требуется юрист. Поэтому стороны сокращают и могут даже устранить любого лишнего человека, который не участвует в договоре.
Снижение затрат
Поскольку контракты не зависят от третьей стороны, затраты снижаются. Меньшее вмешательство человека приводит к снижению затрат.
Скорость
Умные контракты используют программный код для автоматизации задач, которые в противном случае выполнялись бы вручную. Поэтому они увеличивают скорость бизнес-процессов и менее подвержены ошибкам вручную.
Безопасность
Основывая контракты на блокчейне Ethereum, они не могут быть потеряны. Все является неизменным. Ничто и никто не может заставить его исчезнуть, и у вас всегда есть к ним доступ.
Процесс децентрализованного управления исключает риск манипуляций, поскольку выполнение управляется автоматически всей сетью, а не отдельной частью.
Недостатки смарт-контрактов
С другой стороны, программы такого типа также имеют определенные недостатки. Главный состоит преимущественно в использовании технологий, которые он задействует: интернет-вещей и блокчейн.
IoT может обеспечить связь с активами, но ему еще предстоит пройти долгий путь в области безопасности. IoT-устройства легко взломать. Блокчейн более чем безопасен, но он неизменен. После того, как условия согласованы, их нельзя будет впоследствии изменить, что невыгодно для одной из сторон.
Как создать смарт-контракт?
Контракт разработан на определенном языке (Solidity, Serpent или Mutan), скомпилирован в EVM и, за некоторыми исключениями, соответствует стандартному интерфейсу ERC-20. Solidity является языком, который основан на JS, Python и C++.
Чтобы подойти к созданию смарт-контракта, нужно знать Solidity. Как бумажные контракты создаются людьми, которые знают всю правовую среду вокруг них, в умных контрактах необходимо знать компьютерный код, называемый Solidity.
В документе «Введение юриста в смарт-контракты» для смарт-контрактов описываются два «уровня»: платформа смарт-контрактов (SCP), которая представляет собой инфраструктуру, позволяющую создавать их и управлять ими на блокчейне, и система управления смарт-контрактами (SCMS). Этот протокол добавляется к этой инфраструктуре, чтобы пользователю было проще взаимодействовать с контрактами. То есть, он является графическим интерфейсом.
Контракт выполняется в сети, внутри виртуальной машины Ethereum (EVM). Это исполнение не является бесплатным, но оплачивается в форме «газа», небольшого количества эфирной валюты, внесенного одним или несколькими участниками контракта. Важной деталью является то, что исполнение децентрализовано и производится во всех узлах сети. Это одна из причин, по которой EVM работает так медленно и может обрабатывать только около 15 транзакций в секунду.
Как происходит процесс оформления смарт-контрактов
Инфраструктура интеллектуальных контрактов может быть реализована с помощью реплицированных записей, а выполнение контрактов может осуществляться с использованием древа Меркле, который работает через криптографические хеш-функции и репликацию задачи византийских генералов (BFT), которая является обобщенной задачей двух генералов. Каждый узел в одноранговой сети действует как реестр доверия или гарантии, выполняя изменения держателей контракта и автоматически проверяя правила, наложенные транзакцией, а также проверяя ту же работу других узлов. Криптовалюты типа BTC реализовали особые случаи для тех записей или узлов, где собственностью и ядром транзакции являются деньги. BTC и многие его производные содержат более обобщенные механизмы для прав собственности и исполнения контрактов. Ведение кода — очень важная и часть протокола BTC, основанная на репликации конечного автомата.
Как можно использовать смарт-контракты?
В двадцать первом веке существует возможность перевода всевозможных бумажных договоров в цифровые смарт-контракты, а следственно, появляется и широкий спектр потенциального применения.
Автоматизация платежей: контракт может быть запрограммирован, чтобы гарантировать, что требуемая сумма поступит в указанное время указанным лицам или организациям.
Регистрация и смена владельца: необходимые документы могут быть зарегистрированы в блокчейне, чтобы установить собственность с самого начала и сменить владельца посредством интеллектуальных договоров.
Энергетические транзакции: считается, что это создает цифровую экосистему для обмена энергией. Таким образом, источники электричества или топлива будут связаны с смарт-контрактами, заключенными только между физическими лицами или с вовлеченными организациями, которые, в свою очередь, могут персонализировать потребление каждого клиента.
Интеллектуальная собственность: можно встроить смарт-контракт в любой объект, который контролируется цифровыми средствами. Именно здесь рождается «умная собственность», которая может быть ассимилирована с объектами IoT, подключенными к сети. Они могут варьироваться от дома до автомобилей. Таким образом, например, аренда этих свойств может быть автоматизирована.
Также, криптовалюты, такие как Биткоин, можно рассматривать как набор смарт-контрактов, которые обеспечивают соблюдение закона о собственности. Криптографические методы используются, чтобы гарантировать, что их может потратить только владелец цифрового токена. Уже существует несколько децентрализованных рынков активов, так что многие различные цифровые активы могут быть проданы в одной цепочке блоков. Тот же принцип можно распространить и на физические продукты с электронным управлением или встроенными микрочипами.
Финансовые услуги: Криптовалюты, очевидно, открывают широкий спектр различных вариантов использования для умных контрактов, которые иначе были бы невозможны. Например, системы, подобные используемой BurstCoin, могут проводить аукционы, которые автоматически проверяют самую высокую цену в заданный срок и автоматически переводят неактивные средства.
Больше новостей о криптовалютах вы найдете в нашем телеграм-канале РБК-Крипто.
Введение в смарт-контракты
Обычный контракт 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
Давайте сейчас рассмотрим детальнее самый простой смарт-контракт на примере.
Выше приведен упрощенный исходный код, который может удерживать монеты пользователей и возвращать их по требованию.
Итак, есть смарт-контракт 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 платформ смарт-контрактов, то можно привести следующие:
Далее, виртуальная машина может читать данные из базы данных блокчейна, для того чтобы использовать эти данные в качестве триггера для выполнения той или иной логики смарт-контрактов. Виртуальная машина может создавать и отправлять транзакции, она может создавать новые контракты и вызывать методы других смарт-контрактов, которые уже опубликованы в сети: существуют, доступные и т. д.
Наиболее распространенный миф заключается в том, что смарт-контракты Ethereum могут использовать информацию из любых интернет-ресурсов в своих условиях. Правда состоит в том, что виртуальная машина не может отправить сетевой запрос какому-то внешнему информационному ресурсу в интернете, то есть нельзя написать такой смарт-контракт, который будет распределять ценность между пользователями в зависимости от того, допустим, какая погода на улице, либо кто выиграл в каком-то чемпионате, либо на основании того, какое еще происшествие случилось во внешнем мире, потому что информации об этих происшествиях просто нет в базе данных самой платформы. То есть в блокчейне ничего по этому поводу нет. Если оно там не появится, то и виртуальная машина не может использовать эти данные в качестве триггеров.
Недостатки Ethereum
Давайте перечислим основные из них. Первый недостаток состоит в том, что существуют некоторые сложности при проектировании, разработке и тестировании смарт-контрактов в Ethereum (в Ethereum для написания смарт-контрактов используется язык Solidity). Действительно, практика показывает, что очень большой процент среди всех ошибок принадлежит человеческому фактору. Это фактически актуально и для уже написанных смарт-контрактов Ethereum, которые имеют сложность среднюю либо выше. Если для простых смарт-контрактов вероятность ошибки мала, то в сложных смарт-контрактах очень часто встречаются ошибки, которые приводят к хищению средств, к их заморозке, к уничтожению смарт-контрактов непредвиденным образом и т. п. Уже много таких случаев известно.
Второй недостаток заключается в том, что сама виртуальная машина не идеальна, так как она тоже написана людьми. Она может выполнять произвольные команды и в этом кроется уязвимость: можно определенным образом сконфигурировать ряд команд, которые приведут к непредвиденным заранее последствиям. Это очень сложная сфера, но существует уже несколько исследований, которые показывают, что эти уязвимости есть в текущей версии сети Ethereum и они могут привести к отказу работы многих смарт-контрактов.
Еще одна большая сложность, ее можно считать недостатком. Она заключается в том, что можно практическим либо техническим образом прийти к тому, что если скомпилировать байт-код контракта, который будет выполняться на виртуальной машине, можно определить некоторый специфический порядок операций. При выполнении в совокупности эти операции очень сильно нагрузят виртуальную машину и замедлят ее непропорционально той комиссии, которая была оплачена за выполнение этих операций.
В прошлом был уже такой период развития Ethereum, когда много ребят, которые разбирались детально в работе виртуальной машины, находили такие уязвимости. Фактически транзакции платили очень маленькую комиссию, но практически очень замедляли работу всей сети. Эти проблемы решаются очень сложно, так как нужно их, во-первых, детерминировать, во-вторых, скорректировать цену за выполнение этих операций и, в-третьих, провести хардфорк, что означает обновление всех узлов сети на новую версию программного обеспечения, а затем одновременную активировацию этих изменений.
Что касается Ethereum, то было проведено очень много исследований, получен очень большой практический опыт: как положительный, так и отрицательный, но тем не менее остаются сложности и уязвимости, с которыми предстоит еще как-то бороться.
Итак, тематическая часть статьи завершена, перейдем к вопросам, которые возникают достаточно часто.
Часто задаваемые вопросы
— Если все стороны действующего смарт-контракта хотят изменить условия, могут ли они отменить этот смарт-контракт с помощью мультиподписи, а потом создать новый смарт-контракт с обновленными условиями его выполнения?
Тут ответ будет двоякий. Почему? Потому что с одной стороны смарт-контракт единожды задается и он уже не подразумевает никаких изменений, а с другой стороны он может иметь заранее прописанную логику, которая предусматривает полное или частичное изменение каких-то условий. То есть если вы хотите что-то поменять в своем смарт-контракте, то вы заранее должны прописать условия, по которым вы можете обновить эти условия. Соответственно, только таким предусмотрительным образом можно организовать обновление контракта. Но и здесь тоже можно напороться на неприятности: допустить какую-то ошибку и получить соответствующую уязвимость. Поэтому такие вещи нужно очень детально и тщательно проектировать и тестировать.
— А если медиатор войдет в сговор с одной из сторон-участников: escrow или смарт-контракта? Обязателен ли медиатор в смарт-контракте?
Медиатор не обязателен в смарт-контракте. Его может не быть. Если в случае escrow медиатор войдет в сговор с одной из сторон, то да, эта схема тогда резко теряет всю свою ценность. Поэтому медиаторы и выбираются таким образом, что им доверяют одновременно все стороны, вовлеченные в этот процесс. Соответственно, вы просто не будете переводить монеты на multisignature адрес с тем медиатором, которому не доверяете.
— Можно ли одной транзакцией Ethereum перевести много разных токенов со своего адреса на разные целевые адреса, например биржевые адреса, где торгуются эти токены?
Это хороший вопрос и он касается модели транзакций Ethereum и ее отличия от модели Bitcoin. И отличие это кардинально. Если в модели транзакции Ethereum вы просто переводите монеты, то они переводятся только с одного адреса на другой, без сдачи, просто конкретная сумма, которую вы указали. Иначе говоря, это не модель непотраченных выходов (UTXO), а модель именно аккаунтов и соответствующих балансов. Одной транзакцией отправить сразу несколько разных токенов теоретически можно, если написать хитрый смарт-контракт, но все равно придется сделать много транзакций, создать контракт, потом передать ему токены и монеты, а потом вызвать соответствующий метод. Это требует усилий и времени, соответственно, на практике это так не работает и все платежи в Ethereum совершаются отдельными транзакциями.
— Один из мифов о платформе Ethereum состоит в том, что невозможно описать такие условия, которые будут зависеть от данных внешнего интернет-ресурса, как же быть тогда?
Решение состоит в том, что сам смарт-контракт может предусматривать одного или нескольких так называемых доверенных оракулов, которые собирают данные о состоянии вещей во внешнем мире и передают их в смарт-контракты через специальные методы. Сам контракт считает правдой те данные, которые он получил от доверенных сторон. Для большей надежности просто выбирают большую группу оракулов и минимизируют риск их сговора. Сам контракт может не учитывать данные от оракулов, которые противоречат большинству.
Данной теме посвящена одна из лекций онлайн-курса по Blockchain — “Введение в смарт-контракты”.