Платформа Ethereum: Ограничения смарт контрактов и способы их обхода
Смарт контракты в Ethereum являются ключевой его особенностью. Ethereum представляет из себя распределенную блокчейн платформу, для которой можно создать любую математически вычислимую функцию.
Для этого был создан язык программирования Solidity, который близок по синтаксису к JavaScript и является Тьюринг-полным (как и все популярные языки программирования: Java, PHP, Python и т.д.).
То есть смарт контракт является программой, которая скомпилирована и записана в блокчейн и имеет свой адрес в сети. При помощи данного адреса мы можем вызывать код смарт контракта, а сам смарт контракт будет запущен на одной из нод, которая является частью платформы Ethereum.
В отличие от традиционных программ, смарт контракты запускаются в распределенной Ethereum сети и имеют некоторые отличительные особенности и ограничения.
На волне популярности блокчейн и Ethereum ожидания от функционала смарт контрактов могут не совпадать с тем, для чего они предназначены. Вот несколько кейсов, которые не могут быть реализованы при помощи смарт контрактов.
1. Транзакция, которая инициируется по прошествии определенного времени
Главная идея в том, что однажды скомпилированный и записанный в блокчейн смарт контракт получает адрес (наравне с адресом аккаунта), по которому мы можем вызывать его код (публичные методы), и благодаря которым смарт контракт будет совершать определенные действия.
То есть для запуска смарт контракта всегда нужно воздействие извне, вызов от участника сети, у которого есть соответствующие права запуска.
Мы можем установить проверку времени в самом смарт контракте при вызове метода, который инициирует платеж, однако возникает следующая проблема: мы не можем рассчитывать на временную метку блока внутри контракта, так как она может быть изменена майнером, и таким образом нарушить работу контракта либо сделать результат его выполнения непредсказуемым.
Также эта особенность может быть использована для намеренного манипулирования поведением смарт контракта.
Схема работы смарт контракта с отложенным платежем и внешним сервисом, который базируется на проверке временной метки блока (timestamp)
Единственный гарантированный способ сделать отложенный вызов смарт контракта — это привязать проверку текущего времени к количеству сгенерированных блоков.
Мы знаем среднюю скорость генерации блока и можем получить точное количество созданных блоков (однако средняя скорость генерации блоков может меняться).
Нам необходимо периодически запускать смарт контракт и в момент, когда количество блоков будет больше либо равно указанному значению — код выполнится.
В любом случае смарт контракт не может запускаться самостоятельно — для этого нам необходим сторонний сервис, который будет выполнять эту операцию с определенной периодичностью.
Схема работа смарт контракта с отложенным платежем и внешним сервисом, который базируется на проверке количества созданных блоков
Заметка по безопасности: Смарт контракт не должен отправлять Ether в процессе выполнения действий, так как отправка Ether может вызывать другой смарт контракт, который в свою очередь может завершаться с ошибкой (например при неверном адресе отправки Ether).
Мы будем лишь записывать количество Ether, которое может забрать тот или иной адрес и реализуем функцию, которая переводит записанное количество Ether на адрес того, кто его запросил. Этот паттерн для смарт контрактов называется Pull Payment.
2. Транзакции, которые происходят с определенной периодичностью
Тут мы сталкиваемся с той же проблемой, что и в предыдущем примере. Смарт контракт не может быть запущен самостоятельно, поэтому для работы периодических транзакций необходим внешний сервис, который будет периодически запускать код смарт контракта. При достижении условий выплаты смарт контракт переведет средства на адрес, записанный заранее.
Например, мы хотим создать смарт контракт, который будет начислять зарплату сотрудникам раз в месяц. Мы хотим хранить суммы и периодичность платежей, адреса выплат внутри смарт контракта. Периодичность платежей мы будем хранить в количестве блоков, которые должны быть созданы перед зарплатой.
Главная задача смарт контракта — вести счет созданных блоков с момента начала работы контракта и последней выплаты, который будет обновляться раз в сутки благодаря запуску сторонним сервисом.
Схема работы периодического платежа вместе с внешним вызывающим сервисом
3. Получать актуальные курсы обмена валют в смарт контракте
В силу ограничений платформы Ethereum, смарт контракт не может напрямую контактировать с внешними сервисами, а только с другими смарт контрактами и блокчейном.
Решить эту проблему можно несколькими способами:
1). Устанавливать курс в смарт контракте при помощи стороннего сервиса
Сервис будет периодически вызывать метод смарт контракта и передавать в него актуальный курс Ether. В силу распределенности и отсутствия гарантии времени выполнения транзакции мы не можем быть уверены, что при выплате мы будет ориентироваться на актуальный курс Ether.
Поэтомунам необходимо связать изменение курса и выплату зарплат, что требует усложнение кода контракта и координации работы внешних сервисов.
Схема работы контракта с периодическими платежами, которые формируются на базе актуальных курсов обмена валют. Курс обмена валют устанавливается внешним сервисом.
2). Позволить смарт контракту при необходимости самому запрашивать курс
Так как смарт контракт не может взаимодействовать со сторонними сервисами напрямую, ему необходим посредник, который сможет предоставлять информацию извне.
Такие посредники называются оракулами и являются сторонними сервисами, которые коммуницируют со смарт контрактами через постоянное чтение и запись в блокчейн. То есть коммуникация вне системы для смарт контрактов возможна лишь на уровне чтения и записи данных в блокчейн.
Смарт контракт делает запрос к внешнему сервису при помощи смарт контракта оракула, запрос фиксируется в блокчейне и оракул, который постоянно сканирует блокчейн на наличие запросов, делает запрос к сервису.
После чего оракул записывает ответ в блокчейн и шлет сообщение о готовности ответа смарт контракту, который делал запрос. Таким образом мы можем создавать запрос к оракулу на актуальный курс перед каждой выплатой и проводить выплату после того, как будет готов результат запроса.
Если используется оракул от стороннего провайдера, важен высокий уровень доверия к нему, так как все запросы смарт контракта проходят через сервера оракула. Также важно быть уверенным, что сервер оракула совершил необходимый запрос и не подделал данные в ответе.
В сервисе oraclize.it, который предоставляет услуги оракла для подтверждения валидности ответа, используется метод TLSNotary.
Схема получения курса валют через оракул
4. Скрыть транзакцию для остальных участников сети
Мы научились делать выплаты сотрудникам при помощи смарт контракта с определенной периодичностью и с привязкой к текущему курсу Ether.
Однако остается проблема публичности всех транзакций и смарт контракта, так как вся работа с платежами проходит в публичной сети Ethereum, каждый участник может просмотреть все транзакции, которые в ней проводились.
Также мы не можем хранить какие-либо конфиденциальные данные в смарт контрактах, так как они хранятся в публичном блокчейне, который хранится на жестком диске и в оперативной памяти каждого участника системы.
Каждый смарт контракт имеет свою приватную базу данных и переменные, где могут храниться данные, недоступные вне смарт контракта.
Однако, несмотря на то, что мы не можем сделать доступ к приватным переменным и методам смарт контракта из другого смарт контракта, это не мешает опытному программисту получить доступ к необходимым данным, так как смарт контракт является частью блокчейн базы, которая доступна для чтения всем желающим.
Мы не хотим, чтобы посторонние знали о зарплатах наших сотрудников и периодичности их выплат. Мы также не хотим, чтобы сотрудники знали зарплату друг друга.
К сожалению, эту проблему невозможно решить средствами смарт контрактов. В данный момент платформа Ethereum не поддерживает разграничение прав доступа к транзакциям (но поддержку планируется добавить в будущем) и содержанию смарт контракта, поэтому многие организации создают собственные приватные блокчейны на базе Ethereum.
Приватный блокчейн, в отличие от традиционных публичных, обычно представляет из себя закрытую сеть внутри организации, доступ к которой имеет ограниченный круг лиц.
Некоторые из них идут дальше, и создают форк Ethererum (модицируют исходный код) с поддержкой приватных транзакций, разграничением прав доступа к транзакциям, упрощением сложности майнинга (создания новых блоков) и валидации транзакций, так как приватный блокчейн обычно запускается на ограниченном количестве серверов организации (или нескольких организаций).
Наиболее ярким примером форка является Quorum от J.P. Morgan. Quorum поддерживает приватность как транзакций так и смарт контрактов а также имеет облегченный механизм подтверждения транзакций. Quorum является готовым к использованию решением, которое находится в открытом доступе.
Схема ограничения доступа к транзакции в приватном блокчейне Quorum. На схеме показана транзакция, которую Party A отсылает Party B. Транзакция распространяется на все ноды, но доступна для чтения только тем нодам, что могут ее расшифровать (Party A и Party B).
5. Управление платежами вне платформы Ethereum
Смарт контракт не может управлять платежами вне Ethereum. Смарт контракт может манипулировать только Ether и другими валютами, созданными в Ethereum (токенами).
Если мы хотим привязать к работе смарт контракта банковские переводы, нам необходим оракул, который будет постоянно сканировать блокчейн на предмет нужных транзакций и далее проводить их через API банка.
Мы также можем переложить на оракул задачу хранить значения выплат, а через блокчейн только инициировать выплаты, тем самым убирая всю конфиденциальную информацию из смарт контракта.
Благодаря этому мы сохраняем необходимую конфиденциальность проведения транзакций и можем использовать публичный блокчейн Ethereum без необходимости создавать приватный.
Схема работы с оффчейн транзакциями
Ethereum является первой платформой для запуска тьюринг полных смарт контрактов, которая имеет ряд ограничений. Некоторые из них будут устранены в следующих версиях платформы, некоторые из них будут решены в конкурирующих платформах (Lisk, EOS).
Пока же для обхода многих ограничений платформы приходится рассчитывать на традиционные централизованные решения, которые являются своеобразными проводниками из блокчейн сети в интернет.
Также ограничения блокчейн платформ могут быть устранены постепенным переходом от централизованных веб приложений к их децентрализованным аналогам. Таким образом отпадает необходимость в предоставлении высокого уровня доверия к подобным сервисам.
В нашей компании, мы активно развиваем направление блокчейн разработки, включая написание смарт контрактов. На данный момент на нашем счету много успешно завершенных проектов.
В связи с этим мы расширяем нашу команду и ищем специалиста на вакансию блокчейн/node.js разработчика. Если вам интересно это направление, мы готовы предоставить все условия для карьерного и профессионального роста.) (Добавлено 18 июня, 2018)