Прошло почти 15 лет с запуска сети Bitcoin, предложившей миру новый способ передачи ценности, альтернативный традиционным валютам. Всё это время технологии не стояли на месте: к 2023 на основе блокчейна вовсю развиваются проекты в различных сферах экономики — особенно финансовой — а государства всерьез занимаются запуском собственной «крипты», ЦВЦБ. Такой прорыв стал возможен во многом благодаря смарт-контрактам. В этом посте мы расскажем, что такое смарт-контракты, как они эволюционировали и, наконец, как работают на нашей платформе «Конфидент».
Хотя его самые известные истории успеха связаны именно с этим, блокчейн — это не просто способ передачи ценности в виде токенов. Это технология работы с данными в единой среде, участники которой не доверяют друг другу. Блокчейн-сети защищены от злонамеренных участников — в них даже решается известная задача византийских генералов. А благодаря транзакциям можно однозначно отследить все изменения в состоянии сети — в том числе определить авторов сомнительных транзакций. Все транзакции, в свою очередь, защищены от подмены и перезаписи с помощью базовых архитектурных принципов технологии, а также электронной подписи.
В современном мире, со всем его множеством международных и других связей на разных уровнях, технология блокчейна может найти применение в разных сценариях — от логистики до выборов. Но для создания систем требуемой сложности свойств самого́ блокчейна недостаточно. На помощь пришли смарт-контракты — по сути, классические компьютерные программы, которые в качестве инфраструктуры для своей работы используют блокчейн-сети.
Ethereum: начало развития смарт-контрактов
Концепция смарт-контрактов была впервые предложена Ником Сабо — известным ученым в области информатики и криптографии. Популярно мнение, что за псевдонимом Сатоши Накамото скрывается именно Ник, хотя сам он это отрицает. Но что известно точно, так это участие Сабо в разработке технологического стека Ethereum, с которого и началось широкое применение смарт-контрактов. Именно смарт-контракты и их потенциально безграничные возможности обеспечили популярность «эфира» не только у инвесторов, но и у разработчиков по всему миру.
Первые смарт-контракты уже давали возможность выстраивать сложную бизнес-логику на основе блокчейна, но имели особенности, не позволяющие им конкурировать с традиционными приложениями. В частности, весь смарт-контракт должен был помещаться в одну транзакцию, то есть не занимать более 24 КБ — ведь взаимодействие в блокчейн-сети реализовано с помощью транзакций. Впоследствии это ограничение преодолели. Также на раннем этапе смарт-контракты имели ряд «детских болезней» и уязвимостей, которые со временем были побеждены.
В те времена смарт-контракты также не имели доступа к данным вне блокчейн-сети. Сейчас это решается с помощью оракулов. Они поставляют данные из внешнего мира в блокчейн-сеть, работают в соответствии с консенсусом и имеют цифровые подписи. Это большая тема, заслуживающая отдельного поста.
Ethereum стал первой сетью, где получили распространение смарт-контракты, и он сохраняет лидерство по сей день. Многие проекты до сих пор не представляют лучшей среды для своей реализации, и с ними нелегко спорить. Большинство смарт-контрактов Ethereum написано на языке Solidity — он прошел долгий путь развития и когда-то даже поглотил «младшего брата» Vyper. Окружает Solidity богатая экосистема и широкое комьюнити разработчиков.
Базовый механизм работы смарт-контрактов в Ethereum реализован с помощью EVM (виртуальной машины Ethereum) и, по сути, довольно прост. Когда транзакция вызывает смарт-контракт, EVM изменяет стейт сети Ethereum таким образом, чтобы он соответствовал результатам контракта. В каждом смарт-контракте определено количество «газа» для выполнения, оплачиваемое отправителем. По мере выполнения смарт-контракта в рамках транзакции количество этого газа уменьшается, и если оно достигает нуля до завершения транзакции, то все изменения откатываются и смарт-контракт не выполняется. А газ всё равно оплачивается — ведь ресурсы сети были использованы.
Смарт-контракты могут инициировать транзакции и вызывать другие смарт-контракты самостоятельно: для этого в рамках текущей EVC загружается новый, вложенный инстанс EVM. И если на исполнение смарт-контракта не хватает газа, транзакция откатывается на уровень выше. При исполнении смарт-контрактов детерминированный алгоритм преобразует валидные входные данные в ожидаемые выходные данные, и консенсус гарантирует, что результат исполнения у смарт-контракта может быть только один.
Для корпоративных сценариев Ethereum, в силу особенностей само́й сети, подходит не лучшим образом. Ethereum — это публичная и недоверенная среда, что сразу ограничивает ее возможности при работе с непубличными, чувствительными данными; а их доля в корпоративном сегменте очень велика. Другая особенность — это нестабильная, непредсказуемая стоимость «газа» (транзакций), которая может легко выбить масштабный проект за пределы бюджета.
Смарт-контракты в Docker
Теперь рассмотрим, как смарт-контракты реализуют в блокчейн-среде, предназначенной специально для бизнес-проектов. «Конфидент» — это наша основная блокчейн-платформа, на базе которой создаются проекты для разных отраслей.
Смарт-контракты у нас на платформе детерминистически исполняются в контейнеризированной среде с использованием Docker Registry, которая по сетевому слою связана с блокчейн-узлами. Это значительно опускает порог входа для разработчиков: знания любого тьюринг-полного языка достаточно, чтобы написать смарт-контракт.
Исполняться смарт-контракты на нашей платформе могут параллельно; согласованность при этом обеспечивается с помощью метода MVCC. Исполнение смарт-контрактов реализовано в соответствии с политиками валидации. У нас их три: any, majority, majority with one of. Any соответствует общей политике валидации в блокчейн-сети, majority требует ⅔ голосов валидаторов. С Majority with one of всё интереснее: она определяет список узлов, которые должны присутствовать при валидации. Последняя политика повышает надежность сети и защищает ее от злонамеренного использования — то что нужно для бизнес-проектов. Это один из многих механизмов, созданных на платформе с такой целью.
В отличие от Ethereum, корпоративные блокчейн-проекты используют в основном permissioned-сети с достаточно четко прописанными ролями, предназначенными в том числе и для разделения уровней доступа к потокам информации. Например, у нас в рамках платформы есть роль contract-validator, которая позволяет участвовать в валидации исполнения смарт-контрактов.
Смарт-контракты на WebAssembly
Следующий вариант реализации смарт-контрактов, который на сегодня можно признать наиболее совершенным, — с помощью низкоуровневой виртуальной машины WebAssembly. Это сравнительно молодая технология: ее начали развивать в 2017 году. Тем не менее многие уже сейчас видят в ней стандарт индустрии.
В ракурсе использования со смарт-контрактами преимуществ у WebAssembly немало. По сравнению с EVM она обеспечивает лучшую производительность и безопасность. В отличие от Docker-реализации, у WebAssembly отсутствуют сетевые задержки. Поддерживается компиляция разных языков программирования, а также комплексные операции со смарт-контрактами — например, вызов одного смарт-контракта через другой. Есть огромная экосистема, включающая несколько реализаций WebAssembly для разных задач, есть инструменты для создания кастомных реализаций и активное комьюнити разработчиков.
В нашей блокчейн-платформе «Конфидент» реализация смарт-контрактов на WebAssembly будет соседствовать с уже имеющейся Docker-реализацией. Последняя сохранится ради обратной совместимости и перейдет в стадию поддержки. Мы гордимся тем, до какого состояния отполировали Docker-реализацию, и сейчас усилия сосредоточены на WebAssembly. Обязательно расскажем о ней в отдельном посте.
Конфиденциальность в смарт-контрактах
Оценивая смарт-контракты для использования их в бизнес-задачах, мы непременно столкнемся с вопросом конфиденциальности. Конфиденциальность — это свойство безопасности информации, при котором доступ к ней имеют только субъекты, имеющие право на этот доступ. Блокчейн же по определению предполагает, что цепь его блоков не зашифрована и доступна в открытом виде. Стоит ли пытаться это сочетать? Пожалуй, стоит.
У технологии блокчейна есть ряд преимуществ, которые очень привлекательны для конфиденциальных систем. Блокчейн-сети обеспечивают беспрецедентную устойчивость к взлому. С его помощью можно решить задачу византийских генералов. DDoS-атаки плохо работают на децентрализованных протоколах. Единой точки отказа в блокчейне не может быть в принципе. Риски от утечки паролей в блокчейне также довольно ограничены: компрометация приватного ключа одного из участников не сможет ничего дать злоумышленникам. Такая нода просто попадет в бан-лист, что даст сигнал остальным участникам сети (у нас предусмотрена такая возможность).
Как же сделать на основе блокчейна корпоративные информационные системы, сочетающие высокий уровень надежности, заложенный изначально, с необходимой конфиденциальностью?
Самый простой вариант — создать приватную сеть и регулировать состав ее участников. Это исключает случайных участников и гарантирует конфиденциальность. Но что делать, если состав участников сети приходится менять? Или в проекте нужно много сетей для разных задач? Существует подход создания своего рода подсетей: в каждой из них имеются свои участники и правила, но при этом все они объединены основной блокчейн-сетью. При кажущемся удобстве у такого подхода есть два существенных недостатка — высокие трудозатраты и неспособность к горизонтальному масштабированию (при росте нагрузки ботлнеки могут возникнуть в самых неожиданных местах).
Мы для решения этой задачи реализовали на платформе конфиденциальные смарт-контракты (КСК). За основу взяли свою схему обмена конфиденциальными данными — это отдельная фича платформы — и добавили к смарт-контрактам работу с политиками: простой набор правил, определяющий состав участников и метод API для передачи файла. При обмене конфиденциальными данными файлы имеют произвольный размер, их хеш всегда будет уникальным, что обеспечит их целостность и защиту при обмене в конфиденциальном режиме.
Но при работе со смарт-контрактами есть две категории данных, которые не являются произвольными — это входные и выходные данные. Нередко они включают целочисленные значения, хеш которых можно легко вычислить. Это значит, что защита от посторонних глаз через хеш работать уже не будет. Поэтому для защиты данных мы создали дополнительный механизм — криптографический коммитмент, или схему обязательства. Подробное описание этой криптографической схемы заслуживает отдельного поста, здесь же отметим только его основные свойства: наличие фазы передачи скрытых данных, наличие фазы раскрытия данных и связанность данных.
Итак, мы наладили и конфиденциальность, и защиту данных. Но остается еще один вопрос — майнеры. Участники, создающие новый блок для цепочки, узнают о новых данных, в том числе транзакциях исполнения смарт-контрактов, раньше других.
Решая задачу нераскрытия конфиденциальных данных майнерам, мы исходили из того, что важно производителям блоков при их добавлении в цепочку. Чтобы по транзакции собрался кворум, то есть определенный состав подтверждающих участников в соответствии с заданной политикой валидации. Поэтому мы можем дать производителю блока только возможность убедиться в том, что кворум собран и консенсус достигнут. А сами данные закрыть, поскольку для этого они майнеру не нужны.
Так пазл «корпоративного блокчейна», наконец, складывается полностью. Мы сохранили блокчейн-основу с ее устойчивостью и другими преимуществами. Мы реализовали смарт-контракты со сложной бизнес-логикой. При этом обеспечили конфиденциальность, защищенность и гибкую валидацию. С помощью конфиденциальных смарт-контрактов даже объекты банковской тайны можно передавать.
Дополнительные возможности смарт-контрактов: smarter and beyond!
Смарт-контракты хорошо подходят для построения бизнес-логики и различных приложений, но некоторые бизнес-требования здесь требуют поддержки дополнительных функций.
В любом серьезном DeFi-проекте нужно, чтобы смарт-контракты поддерживали операции с токенами. Смарт-контракты нашей платформы поддерживают ряд операций в том числе и с внешними токенами — перевод, выпуск/довыпуск, сжигание и лизинг — и их автоматизацию. Смарт-контракт может иметь и собственный баланс токенов — это также важная фича.
Дополнительные возможности смарт-контрактов — в том числе взаимодействие с токенами — открывают огромный потенциал для финтех-проектов. Сложный DeFi с максимальным TVL и финансовыми услугами? Цифровые активы? Выдача наград? Прозрачное распределенное управление через DAO? Пожалуйста: все необходимое уже предусмотрено в смарт-контрактах нашей платформы. Проект можно развернуть как в нашей основной сети, так и в отдельном public-permissioned или частном блокчейне.
Для корпоративного сегмента не менее важна и такая функция смарт-контрактов, как предоставление ролей. Блокчейн — это инфраструктура для самых ценных данных, поэтому четкое определение ролей здесь очень важно для безопасности. Наши смарт-контракты умеют работать с ролевой моделью, предоставляя нужные полномочия через транзакции. Это удобно: у вас в распоряжении всегда будет вся информация о том, кто санкционировал тот или иной доступ в сети.
Смарт-контракт может предоставить какую-либо роль, только если сам обладает такой ролью. Роли можно выдавать и участникам сети, и смарт-контрактам. Например, роль разработчика смарт-контрактов может предоставить другой разработчик, и при увеличении команды новый сотрудник сможет автоматически получить все необходимые уровни доступа в блокчейн-сети.
Как работать со смарт-контрактами
Выше мы говорили, что развитые платформы имеют готовый инструментарий для работы со смарт-контрактами. «Конфидент» не исключение: у нас есть SDK для создания смарт-контрактов на Java/Kotlin или JavaScript (по ссылкам — посты об SDK на Хабре).
Планы развития
В этом году в направлении смарт-контрактов у Web3 Tech запланировано два больших релиза — это переход на WebAssembly и конфиденциальные смарт-контракты. Каждому из них мы посвятили здесь свой раздел, а после релизов подготовим и отдельные посты. Развернуть нашу платформу можно бесплатно в sandbox-режиме и пользоваться ей до высоты блокчейна в 30000 блоков (10 дней). Если вам интересно узнать и рассказать что-нибудь еще о смарт-контрактах, ждем в комментариях!
Комментарии (5)
pnaydanovgoo
28.09.2023 13:46В частности, весь смарт-контракт должен был помещаться в одну транзакцию, то есть не занимать более 24 КБ — ведь взаимодействие в блокчейн-сети реализовано с помощью транзакций. Впоследствии это ограничение преодолели.
На сколько я знаю в Ethereum это ограничение так и существует. Вот тут про это написано. Обойти это можно использую паттерн Diamond для организации кода. Но получается, что это не блокчейн обошел ограничение)
Смарт-контракты нашей платформы поддерживают ряд операций в том числе и с внешними токенами — перевод, выпуск/довыпуск, сжигание и лизинг — и их автоматизацию.
А как это работает? Расскажите чуть подробнее, как смарт-контракты получают доступ к внешним токенам в других сетях? Или я что-то не правильно понял?
tdOS Автор
28.09.2023 13:46+1На сколько я знаю в Ethereum это ограничение так и существует. Вот тут про это написано. Обойти это можно использую паттерн Diamond для организации кода. Но получается, что это не блокчейн обошел ограничение)
Да, Diamond решает проблему, но это решение силами команды Ethereum.
А как это работает? Расскажите чуть подробнее, как смарт-контракты получают доступ к внешним токенам в других сетях? Или я что-то не правильно понял?
Про это будет отдельный пост, но не в ближайшем будущем, пока другие темы в проработке.
qertis
Планируете ли сделать мост для ETH через LayerZero? Потому то часть контрактов в корпоративном блокчейне хочется связать выходящим во внешний публичный блокчейн.
tdOS Автор
Ваш запрос нетипичен для корпоративного блокчейна. Сейчас такого запроса на связь с публичным блокчейном нет, корпоративные заказчики из соображений безопасности скептически настроены к публичным сетям. Но сам по себе такой проект не представляется сложным: достаточно развернуть собственную сеть на нашей платформе и сделать такой мост в рамках кастомизации, с помощью LayerZero или самостоятельно.
klauss_z
Спасибо за вопрос, мы следим за этим направлением развития, и команда займется им, если возникнет реальная потребность.