Смарт-контракт


Смарт контракт (англ. Smart contract, также self-executing contract, blockchain contract, или digital contract) — это электронный алгоритм, предназначенный для автоматизации процесса исполнения контрактов в блокчейн. Основная идея смарт контрактов – исключить расхождение трактовок условий договора заключившими его сторонами.

История создания

Автором идеи смарт контрактов был Ник Сабо, который в своих работах 1996-1997 годов предложил использовать компьютерные алгоритмы с пользовательскими интерфейсами для проведения сделок в области электронной коммерции. По задумке автора, описание условий контрактов должно было осуществляться с помощью математических инструментов и языков программирования. На практике идею смарт контрактов впервые реализовал Виталик Бутерин в своем проекте Ethereum (2013).

Основные принципы работы

Реализация идеи Сабо стала возможна с появлением технологии блокчейн, которая обеспечивает достоверность и защиту смарт контракта в силу своих свойств:

  • Децентрализованный тип системы. Ни одна из сторон контракта не может изменить текст документа, поскольку копия договора хранится в реестре, распределенном между многими узлами сети.
  • Открытые базы данных. Условия контракта доступны всем участникам блокчейн – упрощается аудит исполнения контрактов.
  • Формализация условий контракта. Проверка и выполнение условий договора осуществляется программным кодом (if-this-then-that (IFTTT)), поэтому исключается возможность неправильного исполнения договора.
  • Атомарные операции. Контракт либо будет успешно реализован, либо не выполнится вовсе.
  • Полнота по Тьюрингу. Блокчейн, представленный в Ethereum, имеет встроенный Тьюринг-полный язык разработки смарт контрактов, благодаря которому пользователи сами могут создавать любые контракты.

Исполнение смарт-контракта

В Ethereum код смарт контрактов исполняются в определенной среде – виртуальной машине Ethereum (EVM). Каждый узел сети проводит верификацию нового блока, проходя через транзакции, включенные в этот блок, и реализуя инициируемые этими транзакциями код в EVM.

  • Каждый узел сети выполняет одни и те же вычисления, сохраняет одинаковые значения
  • Формирование майнерами блоков из транзакций осуществляется за плату: стоимость проведения операции измеряется в единицах газа.

Безопасность и уязвимости

Смарт контракты в Ethereum уязвимы к хакерским атакам по ряду причин.

1. Ошибки использования языка

  • Семантика языка Solidity. Контракты создаются на языке программирования Solidity, напоминающий Java, и представляют собой набор функций. Однако байт-код виртуальной машины Ethereum не поддерживает работу с функциями, поэтому перед отправкой в блокчейн контракты компилируются. Одна опечатка в строке кода контракта может привести к реализации функции fallback.
  • Неправильный порядок исключений. Для реализации смарт контракта может понадобиться прерывание работы его метода – исключение. Если исключение возникает во время выполнения команды call, то исполнение контрактов будет продолжаться, пока не закончится газ.
  • Реентерабельность. Одни и те же инструкции программы могут быть введены несколько раз, например, через функцию fallback, что приведет к циклу в вызове метода call и расходованию всего газа. Атака на DAO была построена по этому типу.

2. Ошибки работы виртуальной машины Ethereum

  • Неизменность контрактов. Контракт, опубликованный на блокчейн, невозможно изменить. Если контракт содержит баг, то исправить его невозможно, можно лишь прекратить исполнение контракта. Яркий пример — устранение последствий атаки на смарт контракты DAO.
  • Потери эфира при переводе. Чтобы отправить эфир, необходимо указать адрес принимающей стороны, который представляет собой последовательность из 160 битов. Если предоставленный адрес не привязан к пользователю или контракту, то оправленный эфир будет утерян навсегда.

3. Ошибки в блокчейн

  • Состояние контракта. Одна из проблем смарт контракта это то, что часть транзакций, попавшая в короткую цепь ответвления, не будет реализована. Соответственно на время статус контракта не будет однозначно определен. Одна из сторон контракта может считать, что контракт был исполнен, хотя этого не произошло.
  • Временные ограничения. На определение состояния контракта требуется время (см предыдущий пункт), что делает его уязвимым для атак.

Крупные случаи мошенничества

В июле 2016 года была проведена атака на DAO, в результате которой хакеру удалось перевести на баланс созданного им контракта свыше $64 млн. Для атаки использовалось свойство реентабельности: в рамках одной транзакции хакер снимал средства DAO и переводил эфиры в их дочернее DAO, многократно повторяя операцию.


См. также

Примечания