В последнее время смарт-контракты стали широко использоваться в сети Ethereum, в основном для проведения ICO и управления выпущенными токенами.
Такие контракты заключаются столько времени, сколько необходимо для обслуживания проектов, обеспечивая при этом бесперебойное взаимодействие с тысячами клиентов на протяжении месяцев.
Мы будем называть их долгосрочными смарт-контрактами.
Однако некоторые задачи требуют, чтобы контракт был выполнен буквально за минуты, после чего он уже не нужен.
Более того, каждому пользователю могут потребоваться специальные параметры; реализовать их в рамках крупного контракта нецелесообразно.
Такие контракты мы будем называть краткосрочными.
Давайте рассмотрим их подробнее в этой статье.
Развертывание смарт-контракта Смарт-контракт можно рассматривать как автоматизированный кошелек: вы кладете в него деньги, он проверяет условия и либо возвращает деньги, либо переводит их на другой кошелек, либо отправляет на десять таких кошельков.
Но эта аналогия неполная, давайте попробуем другую.
Давайте сравним договор с сайтом.
Вы разработали сайт, разместили его в Интернете, и провайдер прописал в DNS, что определенный сайт находится по адресу www.company.com. Размещение контракта в сети Ethereum можно рассматривать аналогичным образом: вы разработали код, разместили его в сети (то есть отправили специальную транзакцию «создать контракт») — и контракт получил собственный адрес в Ethereum, а именно то же самое, что и адрес, который вы даете кому-то, чтобы они могли отправлять вам эфир.
В то же время «сайт» в Ethereum обладает свойствами, полезными для смарт-контрактов:
- Код сайта не может быть изменен .
Лучшее, что вы можете сделать, — это заранее запрограммировать возможность «разрушения» контракта при получении специального сообщения.
Это не означает, что код исчезнет или смарт-контракт будет стерт. Просто любая отправленная на него транзакция вернет ошибку.
- Каждый запрос к «сайту» — это неоспоримая транзакция, навсегда сохраняемая в блокчейне.
.На ICO вы внесли один эфир и получили десять токенов — внутри контракта появилась запись о том, что у вас есть десять токенов.
Ваш запрос изменил статус контракта.
Каждая такая транзакция технически неоспорима.
Вы всегда можете доказать, что транзакция была и именно вы ее подписали (при наличии необходимого секретного ключа).
- Каждый запрос пользователя на «сайт» может содержать любое количество средств.
.Если рассматривать контракт как сайт, то каждый запрос к «сайту» может переносить эфир.
Представьте себе сайт, где за каждое нажатие кнопки можно привязывать любую сумму денег, и сайт понимает, сколько на него отправлено, умеет давать сдачу и т. д.
- Каждый запрос виден всем .
Вы не можете ограничить видимость запросов «сайтом».
Вы отправили запрос на смарт-контракт, и во время исполнения что-то сломалось — это нормальная ситуация для Ethereum, и транзакция, вызвавшая ошибку, все равно будет помещена в блоки, а майнеры все равно получат свою комиссию за выполнение кода контракта ( из вашего эфира, конечно).
Не забывайте также, что каждая транзакция, отправляемая в блокчейн, — это данные, подписанные электронной подписью со всеми ее преимуществами (хотя бы с подтверждением авторства).
Почему здесь блокчейн? Говоря простыми словами, дело в отсутствии общей тайны, известной обеим сторонам.
ПИН-код, хэш открытого пароля, небезопасный веб-сеанс — все это примеры того, чем может воспользоваться злоумышленник.
В случае блокчейна единственным секретом является ключ на клиенте; все остальное не требует ни защищенных каналов связи, ни авторизации.
Ну и добавим еще, что ни одна из сторон не может сделать что-то незаметно для другой стороны: фиксируется каждое изменение состояния контракта, даже неудачные или вредоносные транзакции.
Блокчейн записывает любую операцию, которая что-то меняет в хранилище каждого смарт-контракта, размещенного в сети.
При этом операция может быть простой, а может делать достаточно сложные вещи, и любой участник сети абсолютно уверен, что код контракта у всех участников работает точно так же, как и на его машине.
Даже в своей минимальной (краткосрочной) форме смарт-контракты являются отличными инструментами бухгалтерского учета.
Их чрезвычайно удобно использовать практически в любом проекте, поскольку «из коробки» мы получаем всю систему безопасности и отказоустойчивости.
Как мы увидим позже, иногда даже минимума стандартных функций достаточно для реализации многих интересных задач.
Долгосрочные и краткосрочные смарт-контракты Под сроком действия контракта в этой статье я подразумеваю не только время, но и количество транзакций, обслуживаемых контрактом.
Если контракт действует в течение длительного времени, принимает и отправляет множество транзакций, он считается долгосрочным.
Если он принимает несколько транзакций или работает ограниченное время, а затем закрывается, то он краткосрочный.
Мы разделили контракты на два типа, получив опыт разработки нескольких контрактов и проектирования протоколов связи.
Эти контракты имеют разную газовую экономику, сложность создания, характер отправки в сеть и помогают решать разные бизнес-задачи.
Некоторые контракты обслуживают множество пользователей и транзакций и хранят много данных.
Другие используются разово, для фиксации и исполнения одного договора (продажа одного товара, внесение разового платежа, получение ранее заложенных в договор средств и т.п.
).
Поэтому мы навскидку назвали контракты долгосрочными и краткосрочными.
Если у вас есть идеи, как их назвать точнее, добро пожаловать.
Долгосрочные контракты .
Обычно бизнес-модель долгосрочного контракта выглядит так: мы размещаем его в сети Ethereum, и теперь тысячи пользователей заходят на контракт и что-то в нем делают. В качестве примера возьмем контракт токена.
Мы публикуем в сети контракт, хранящий балансы пользователей.
К нам приходят тысячи инвесторов, и для каждого инвестора информация о количестве полученных токенов размещается в контракте токена.
Каждый раз, когда вы отправляете токены на другой адрес, вы получаете доступ к одному и тому же контракту, расположенному на том же адресе, и даете контракту команду изменить баланс токенов (ваш и получателя).
Контракт несет в себе большой объем данных и действует до тех пор, пока живет ваш проект. Токены внутри него могут перемещаться годами.
Ограничений на передачу токенов внутри контракта нет, и она будет работать всегда, пока существует сеть.
Еще одним примером долгосрочного контракта является Equity. Рассмотрим пример компании, в которой вы раздаете акции: 10% Васе, 10% Пете, а вы - 80%.
Вы хотите, чтобы вся прибыль компании распределялась соответственно: если пришло 100 рублей, Вася и Петя получают по 10, а вы - 80. Собственный капитал делит деньги на потоке, распределяя поступающие средства, и позволяет участникам бесспорно получить свои доли, при этом фиксируя все платежи и суммы.
Но планируется, что компания будет работать долго, поэтому вы один раз просите программиста разместить ваш контракт в сети, а затем годами без дополнительных усилий спокойно пользуетесь контрактом, иногда перераспределяя доли.
Краткосрочные контракты .
Живут недолго (часы, дни) или выполняют мало операций (разовый платеж, пара записей событий).
Эти контракты предназначены для отдельного пользователя, отдельной транзакции или отдельного продукта.
Например, при продаже стиральных машин можно разместить в сети договор на каждую машину.
Пользователь заключает такой договор, делает что-то один-два раза (переводит средства, что-то подтверждает) — и после этого взаимодействие заканчивается.
От краткосрочных контрактов нам нужен только разовый ввод-вывод средств с необходимыми проверками и записью события в блокчейн.
Как минимум, любая транзакция, с эфиром или без него, сама по себе является информацией.
В общем, нам ничего в него писать не надо: там уже есть подпись отправителя и время закрытия блока.
Если по контракту можно принимать и выдавать только фиксированную сумму средств (и выдавать, например, сдачу), то любая успешная транзакция становится аналогом кассового чека, а блокчейн становится удобным хранилищем данных транзакции.
Если транзакция завершилась, это означает, что покупка завершена.
Показав ФНС ETH-адрес магазина, вы можете объяснить: «Вот наши чеки и наши продажи».
Это полностью исключает необходимость наличия в магазинах кассовых аппаратов; теперь их забота — зарегистрировать ключи и адреса, принадлежащие магазину, и обеспечить их безопасность и возможность изменения в случае взлома.
Также можно без проблем реализовать оплату налога непосредственно при покупке в пару строк, чтобы было где платить.
Разовые контракты имеют свои преимущества и недостатки.
Тот факт, что контрактов много и они маленькие, сильно увеличивает стоимость размещения в сети Ethereum, ведь это довольно дорогая операция.
Но контракты предусматривают относительно небольшие суммы; их гораздо проще заменить, просто перейдя на новую версию.
Риски безопасности намного ниже из-за простоты кода и небольшого объема данных.
Простота кода также означает низкую стоимость для пользователей.
Есть еще несколько моментов, но о них позже.
В качестве примеров опишем, скажем, три типа простых краткосрочных контрактов:
- Счет оплачен;
- совершить-показать;
- одноразовая мультиподпись.
Идти.
Счет оплачен 
Фактически перед нами ценник.
Представьте, что мы продаем арбузы.
Выдаем ценник непосредственно на конкретный фрукт с конкретным весом, приклеиваем его на арбуз и пишем: «Стоит 1 ETH».
После этого нам нужно, чтобы ценник либо принял 1 ETH, либо «сгнил» через день: возможно, на следующий день мы хотим продать арбуз за 2 ETH. В краткосрочной версии мы публикуем короткий контракт на конкретный продукт на ограниченный период времени.
Из внутренних данных контракт содержит только цену и время, когда контракт становится недействительным.
Когда кто-то хочет купить товар, он отправляет эфир на наш одноразовый контракт, который, в свою очередь, отправляет эфир на адрес ETH магазина, отправляет сдачу (при необходимости) и закрывается.
Транзакция сохраняется в блокчейне, и анализируя транзакции из контрактов, созданных магазином, легко получить всю историю продаж.
В момент покупки по контракту также могут выплачиваться налоги или комиссии лицу, которое привело к нему клиента.
Еще одна достаточно близкая аналогия такого контракта-ценника — счет-фактура.
Поэтому мы и назвали договор оплаченным: это два рабочих состояния, в которых он может находиться.
В режиме счета-фактуры он ожидает оплаты; в платном режиме принимает оплату и ничего не делает. Третье состояние, когда истекло время жизни (TTL — time-to-live), является стандартным для всех краткосрочных контрактов.
Срок жизни с истекшим сроком действия приводит к самоуничтожению контракта или простому игнорированию любой входящей транзакции.
В счете-фактуре можно разместить полезные данные, например, выставить такой счет на определенный адрес прямо в тот момент, когда покупатель решит приобрести товар.
В этом случае контракт принимает эфир строго с указанного адреса.
В договор можно добавить хеш любых данных: фотографию товара, id объявления на Авито, архив с пакетом документов и т.д.
Фиксация-раскрытие 
Эта схема в блокчейне используется, чтобы пообещать что-то сделать, а затем доказать, что дело было сделано.
При отправке транзакции в сеть любой узел, передающий транзакцию по сети p2p, может проанализировать содержимое транзакции до ее включения в блок.
Такой узел может создать собственную транзакцию с более высокой комиссией, которую производители блоков с большей вероятностью включат в блок и которая будет стоять выше в списке транзакций, чем исходная.
Давайте вспомним игру «камень, бумага, ножницы».
В этом случае вы не сможете играть в нее, напрямую отправляя транзакции.
Понятно, что «ножницы» к контракту я не отправлю: мой оппонент может подсмотреть публичную сделку и создать свою, с «камнем».
Решение задачи заключается в схеме, где инициатор (в нашем примере их двое, я и мой оппонент) «обещает» в будущем проявить некую ценность, которая пока остается тайной (наши «ножницы» или «бумага »).
Для этого мы сначала отправляем в контракт хеш слова «ножницы» (я), затем хэш слова «бумага» (мой оппонент).
Только тогда я смогу открыто публиковать «ножницы», а мой оппонент – «бумагу».
Схитрить здесь невозможно: я раскрою «ножницы» только тогда, когда увижу хэш решения оппонента, то же самое касается и его.
Смысл этапа размещения хэшей хорошо передаёт слово commit, а этап раскрытия значений — «reveal», отсюда и название.
Следует отметить, что перед вычислением хеша строку («ножницы» или «бумага») необходимо дополнить случайным числом.
Возможность «угадать» выбор оппонента на основе опубликованного хеша зависит от криптостойкости числа, поэтому к его генерации нужно подойти со всей серьезностью.
Этот номер является временной тайной; он публикуется вместе со строкой на этапе раскрытия, чтобы участники могли проверить правильность хеша.
Давайте рассмотрим вариант контракта commit-reveal для оплаты курьерской доставки.
Магазин отправляет курьера вместе с товаром к клиенту и хочет, чтобы курьер получил оплату только в том случае, если он доставит товар в течение трех часов и доставит его лично клиенту.
Для этого магазин генерирует секретное слово, создает контракт, помещает в него хеш слова и времени (три часа), после чего магазин может просто вернуть свои средства, отправив на контракт транзакцию возврата.
Магазин дает курьеру (в мобильном приложении или браузере) адрес договора, и курьер видит, что сможет забрать оплату через три часа, если узнает секретное слово.
Само слово магазин отправляет клиенту по SMS. Логика контракта описывается фразой «Если курьер в течение трех часов отправит слово — прототип хэша, использованного для создания контракта, я отправлю курьеру средства».
В случае конфликта с покупателем магазин сам может разблокировать средства курьеру, просто отправив ему секретное слово.
Конечно, для реального использования контракты тоже содержат модификации — дополнительные данные и проверки, комиссии, пороги входа, динамическое изменение стоимости доставки и т. д. Но основная схема фиксации-раскрытия является основой для построения удобных протоколов взаимодействия между бизнес-агентами.
Одноразовая мультиподпись 
Этот контракт представляет собой адрес, с которого можно вывести средства, предоставив N из M подписей.
Допустим, муж и жена решили сохранить часть своих семейных сбережений в криптовалюте.
Хотелось бы, чтобы договор принимал и хранил средства, но не позволял выводить их из договора до тех пор, пока не будет получено хотя бы два подтверждения из трех – от мужа, жены или банка.
Если у жены украли телефон, муж может пойти в банк и, получив подпись банка, забрать деньги.
Обычно средства из контракта снимаются, когда и муж, и жена предоставили свои подписи.
Это крайне удобно, поскольку взлом одного из участников не грозит несанкционированным выводом средств.
В целом мультиподпись может работать с произвольными N и M, но ее вариант «два из трех» охватывает огромное количество бизнес-задач, где требуется третья сторона.
Когда вы покупаете квартиру и банк выдает вам ключи от шкафчика только тогда, когда получает документы на недвижимость, это мультисиг 2/3. Деньги зачисляются на мультиподписной адрес, в котором участвуют продавец квартиры, покупатель и банк.
Банк, как только видит договор о смене собственника, ставит свою электронную подпись.
Такой договор также включает в себя сроки и, конечно же, комиссию для банка.
Для разовых задач, предполагающих большие суммы, разумно использовать разовые контракты.
Уязвимость огромного универсального контракта, который будет управлять всеми аккредитивами, может привести к гораздо более серьезным последствиям, чем успешная атака на одноразовый контракт. В целом мультисиг - это как автомат Калашникова, с помощью кратковременных мультисиг 2/2 и 2/3 легко реализуются транзакции с эскроу, транзакции требующие коллективного решения, и дальнейшее добавление функционала к мультисиг и динамические изменения Н и М - это уже переход к совместному голосованию и управлению (но это тема отдельной статьи).
Преимущества краткосрочных смарт-контрактов
- Простота и, как следствие, безопасность.
В Solidity приходится думать буквально о каждом шаге, каждая операция стоит газа, каждый лишний вызов внешнего контракта — это потенциальная уязвимость, и именно здесь кроется большое количество проблем с безопасностью.
Краткосрочный контракт содержит мало кода и не требует взаимодействия с другими контрактами, поэтому он более безопасен, чем его старший долгосрочный брат.
- Чем меньше кода, тем дешевле.
Дешевле публиковать, разрабатывать и писать тесты для него.
Простой контракт имеет более простой и унифицированный интерфейс, который можно легко представить в любом конструкторе.
Это позволяет другим разработчикам работать с вашими смарт-контрактами, легко адаптируя их под свои нужды.
- Краткосрочные смарт-контракты легко перенести на другие блокчейны.
Если вы делаете простой краткосрочный смарт-контракт, скорее всего, вы сможете без проблем реализовать его на Graphene, EOS и других платформах.
Логика простая - скорее это уже реализовано в конкурирующих движках, а значит разработка дешевле и контракт надежнее.
- Очень удобно исправлять.
Дырка в жетоне – серьезная проблема.
Вам придется заменить токен и перетащить баланс — это стоит огромного количества газа.
В случае с краткосрочными версиями мы не развертываем контракты, а исправляем их версию, а затем просто ждем, пока плохие контракты «сгниют» и будут заменены новыми версиями.
- Правильно уничтожая контракты, мы очистим локальное хранилище на клиентах, оптимизируя используемое пространство.
Здесь еще есть тонкий момент, удаляет ли selfdestruct контракт из БД хранилища физически на клиенте, но, по идее, так и должно быть.
Это позволит вам не сильно раздувать объем блокчейна.
- ТТЛ.
Если мы ищем в блокчейне контракты с ценниками и знаем, что они действуют не более суток, то поисковую систему Ethereum можно настроить на работу только с блокчейном за последний день.
Это делает такие поисковые системы удобными и быстрыми, так как данных мало, а сайты, работающие по краткосрочным контрактам, очень быстрые и функциональные.
В противном случае управление сотнями гигабайт блокчейнов и отслеживание тысяч учетных записей — непростая задача для программистов.
Первая проблема – газ.
За каждое развертывание смарт-контракта вам придется тратить газ.
Сервис, обрабатывающий десятки тысяч контрактов, требует серьезных исследований и балансировки.
В Ethereum сегодня вы можете отправить транзакцию по цене газа в 5 Gwei, и она поступит через минуту.
А иногда приходится заплатить 50 гвей за бензин и ждать час.
Те, кто использует смарт-контракты, не очень рады росту цены эфира, поскольку это означает увеличение стоимости отправки контрактов в сеть.
Публикация контракта в Интернете – дорогостоящая процедура, поэтому краткосрочные контракты – удовольствие недешевое.
Мы рассматриваем не только Ethereum и на нашей платформе планируем использовать сразу несколько сетей, работающих со смарт-контрактами.
Вопрос стоимости исполнения является общей проблемой среди них.
Рано или поздно она будет решена – или конкуренция за стоимость исполнения одной строки контракта сильно снизит стоимость.
Кроме того, скорее всего, даже одни и те же типы операций будут отличаться по стоимости, поэтому я не исключаю появления стратегий типа «исполняем контракты с криптопреобразованиями в одном блокчейне, а со строковыми операциями — в другом».
Вторая проблема — контракты, которые мертвы, но не завершены самоуничтожением.
Мы «вытащили» смарт-контракт, заплатили за него, и он умер в блокчейне, ничего не сделав.
Для госбазы это нехорошо, и мы думаем, что придумать.
Возможно, вайпер-скрипты будут вызывать самоуничтожение контрактов с истекшим TTL за небольшую комиссию.
:) Третья проблема — сложная инфраструктура отправки контрактов в сеть.
Управление таким количеством смарт-контрактов, их развертывание и мониторинг требуют серьезного дополнения к Ethereum и другим блокчейнам.
Это поисковая система на блокчейне, автоматический деплоер и очереди для управления пушами для мобильных клиентов, а также управление средствами с большими объемами эфира, адресов и ключей.
Это все очень серьезная история с точки зрения как безопасности, так и архитектуры.
Итак, мы рассмотрели некоторые особенности смарт-контрактов, описали несколько кейсов и немного рассказали о проблемах и решениях.
Уже ведется строительство платформы, которая сможет поддерживать запуск большого количества различных типов контрактов, не жертвуя при этом безопасностью и децентрализацией — это наш проект Smartz.io .
Платформа дает разработчикам и небольшим командам возможность зарабатывать деньги, размещая свои DApps, а для обычных пользователей предоставляет удобный способ запустить и начать использовать одно из множества полезных DApps для личного использования в несколько кликов.
Давайте узнаем друг друга :) Теги: #блокчейн #Децентрализованные сети #Алгоритмы #Криптография #Solidity #Solidity #Ethereum #смарт-контракты
-
Что Такое Волны И Зачем Они Нам Нужны?
19 Oct, 24 -
Как Пропал Ноутбук Ашманова И Другие Курьезы
19 Oct, 24 -
Сервис Экспорта Новостного Контента
19 Oct, 24 -
Учебник 5 По Rabbitmq — Темы
19 Oct, 24
