The DAO и учение Дао. Аварийный выход

Крупнейшее ограбление в истории США – в 1997 году на заводе Dunbar Armored были похищены 18,9 миллионов долларов (это около 27,9 миллионов в сегодняшних деньгах). Недавняя уязвимость в коде The DAO унесла 53 миллиона. По сравнению с этой суммой, ограбление в Данбаре – карманная кража.

В предыдущих постах моих коллег по IC3 Эмина Гюн Сайера и Фила Дайана подробно рассмотрены технические аспекты уязвимости и показана необходимость технических предохранителей, таких как формальная верификация, тщательный дебаггинг и новые возможности высокоуровневых языков программирования. Предохранители, вместе с независимыми от программного кода спецификациями, отдельно создаваемыми для каждого контракта, должны лечь в основу разработки смарт контрактов нового поколения.

Избежать повторения судьбы The DAO поможет не только предотвращение атак, но и создание аварийных выходов

Несмотря на принимаемые меры предосторожности, новые уязвимости, подобные той, что была обнаружена в The DAO, будут и дальше попадаться в смарт контрактах. Это неизбежно. В комплексной и динамичной среде смарт контрактов Эфириума практически невозможно избежать ошибок кода и непредвиденных уязвимостей. Перечисленные выше технические решения не смогли бы предотвратить возможных проблем, описанных в Предложении моратория The DAO Сайера, Замфира и Марка, так же как и рекурсивного вызова, которым воспользовался злоумышленник, атаковавший The DAO. Моделирование ошибок, комплексные взаимозависимости контрактов и другие процедуры могут привести к тому, что контракты перестанут отражать изначальные замыслы своих создателей.

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

Основное предложение состоит в том, чтобы включить в смарт контракты «аварийные выходы» – четко прописанные процедуры модификации и расторжения контрактов в свете непредвиденных обстоятельств (то, что полностью отсутствовало в The DAO). Именно на этом я настаивал в октябре 2015 на форуме DEVCON1 (тогда Slock.it был известен в основном, производством дверных замков), затем в мае на конференции IC3, и буду отстаивать в совместной с Ari Juels работе, которую я представлю 9 июля на симпозиуме RuleML 2016.

Аварийные выходы могут и должны базироваться на Контрактном Праве

Гудини найдет выход

Хорошая новость заключается в том, что создавая аварийные выходы для смарт контрактов, нам не нужно начинать с нуля. В реальном мире, в контракты уже включены разного рода аварийные выходы, базирующиеся на существующем контрактном праве. За долгий срок правовое сообщество определило и отладило обширный набор средств исправления ошибок, и действий в непредвиденных обстоятельствах для обычных контрактов (модификация, реформирование, завершение, аннулирование). Мы просто можем преобразовать их в аналогичные инструменты в смарт контрактах.

В свете атаки на The DAO, важнейший урок, которому учит нас контрактное право, заключается в том, что аварийные выходы просто должны существовать. В мире смарт контрактов, в настоящее время, они отсутствуют. В контрактном праве они присутствуют со времен Древнего Рима, когда actio redhibitoria (аннулирование и реституция), т. е., отказ от контракта, и возвращение обеих сторон к предыдущему состоянию, был одним из основных средств, применяющихся в случае, если кто-то продал вам на рынке гнилые фрукты. Конечно, контракты в оффлайне могут быть изменены после окончания их действия. Смарт контракты – нет. Это означает, что создание аварийных выходов потребует значительных усилий от разработчиков программ, библиотек, платформ, языков программирования, а также от команды Эфириума.

Как пункт об аварийном выходе помог бы сэкономить кое-кому 53 миллиона

Проблемная функция в DAO.sol – splitDAO, уязвимая к рекурсивному вызову. Как показал Фил Дайан, атака требует от ее инициатора множественных вызовов splitDAO. Если бы в коде был аварийный выход, он бы остановил исполнение splitDAO или заморозил ее исполнение до выяснения, а вывод средств из The DAO был бы остановлен сразу после обнаружения.

Остановка splitDAO – худшее решение из возможных, потому что она бы полностью парализовала работу The DAO. Тем не менее, подходящий механизм нейтрализации было бы легко запрограммировать ( и это давно должно было быть сделано). Можно было снабдить функцию splitDAO логическим оператором, который активировался бы, к примеру, кворумом сообщества, кураторами The DAO, или наблюдателями Эфириума. Такой предохранитель пригодился бы и в других недоброкачественных контрактах с таким же багом, как в The DAO. Это может стать самым распространенным решением в смарт контрактах.

Замена функции splitDAO на версию без бага лучше, чем ее отключение, поскольку работа The DAO должна быть продолжена. Такие способы есть. Например, функция splitDAO – да и любая из функций DAO.sol – может быть разделена на несколько отдельных смарт контрактов. Для вызова таких сателлитных контрактов DAO.sol будет использовать функции-указатели с помощью внешних адресов и ABI, которые записаны в легко заменяемых строках-переменных. Если в одной из функций возникает проблема, просто создайте новую и смените указатель в основном контракте. (Конечно, не каждый будет обладать доступом к изменению указателей, так что придется ограничить доступ к замене переменных).

Этот подход, как мне кажется, и есть то направление модификаций контракта, на которое намекал Виталик в описании DAO. Если мы будем строить модифицируемые контракты таким образом, мы получим ситуацию, в которой сможем оперативно реагировать на баги и другие непредвиденные обстоятельства. Далее, если защита встроена в функции, инициирующие замену переменных (при получении одобрения всех сторон, и, возможно, при выполнении определенных условий), может быть обеспечена необходимая гибкость, которая не будет угрожать неизменяемости смарт контракта (которая, несомненно, является ключевым условием).

Как аварийные выходы работают на возмещение ущерба, а не только на его предотвращение

В предыдущих главах приведены наброски простейших предохранителей, доступных всем уже сейчас. В реальности, однако, аварийные выходы контрактного права – довольно сложные механизмы, некоторые из их особенностей могут послужить и нам. Например, аннулирование в контрактном праве не только отменяет контракт, но и требует, чтобы стороны вернулись в первоначальное состояние, это касается любых частичных действий, все должно стать «как было». Кое-кто надеялся на аналогичную модель в The DAO, и в идеальном случае, экстренный выход смарт контракта сможет выполнить и эту задачу, может быть, даже автоматически (для того, чтобы минимизировать вмешательство судов, и других подобных структур).

Представим, к примеру, что выплаты The DAO проводят некоторое время в карантине на временных эскроу-счетах, которые, в случае роспуска The DAO, автоматически выплачиваются инвесторам в соответствующей пропорции. Если бы такой тонкий механизм в свое время был вставлен в контракт, мы могли бы сейчас принять вариант аннулирования The DAO, с немедленным возвратом средств инвесторам, и хоть завтра начать с чистого листа, с исправленным контрактом.

Кто будет контролировать такие операции? Контрактное право дает однозначный, совершенно прозрачный ответ: только стороны контракта и суды имеют право изменять и аннулировать контракты. Мы также можем создать протокол, который позволяет нажать кнопку аннулирования при условии единогласного голосования, или «доверенного посредника» (пример – разработчики Эфириума). Мне могут возразить, что последний способ подрывает распределенную природу блокчейна. Однако то же самое можно сказать о структуре The DAO с ее кураторами. Призывы к основателям Эфириума о форке всей сети Эфириума из-за атаки имеют ту же природу. Фактически, модель централизованного управления, или точнее, смешанная модель, которая сочетает центральное управление с консенсусом, уже используется в The DAO. При том, что архитектура блокчейна обеспечивает дополнительную ответственность управленцев, мы смело можем использовать такую модель для создания аварийных выходов.

Итоги

Мой вывод: чтобы создать детализированные и надежные аварийные выходов, нам необходимо больше исследований. Нам нужно больше инженеров для создания и тестирования таких программ.

Разработчикам Эфириума следовало бы продумать глобальные аварийные выходы – вроде программы-терминатора, удаляющего токсичные контракты из блокчейна (неважно, включена ли такая функция в сам код контракта), или шаблонного предохранителя, который позволит отменить любой контракт с согласия всех сторон. На этой неделе появились и другие идеи (такие как этот контракт, предлагающий введение «безопасного режима»).

На микроуровне есть смысл стандартизировать коды аварийных выходов для всех контрактов и поместить их в открытые библиотеки. Это не только сделает коды выходов многоразовыми, но и подвергнет их более глубокому изучению со стороны пользователей. При создании кода мы должны опираться на те же инженерные принципы, которые я упомянул в начале этой колонки: формальная верификация, тщательное моделирование, минимальный размер кода. И конечно, необходимы инвестиции (как бы там ни было, The DAO проявило немыслимую щедрость, и тем самым привлекло всеобщее внимание к багу).

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

Наконец, уже слишком поздно делать что-либо с предохранителями в The DAO. Однако не поздно построить их для будущего и предотвратить убытки – или, принимая даоистское мировоззрение, минимизировать их – в The DAO v.2.

P. S.

Любопытный комментарий к исходной статье:

В. Бутерин: Забавно, что сплиттинг в The DAO задумывался как раз в качестве специального аварийного выхода. И вот именно он-то и оказался источником уязвимости. Так может быть, нам надо больше работать над стандартизацией уже существующих аварийных выходов и их модернизацией.

Источник: https://hackingdistributed.com/2016/06/22/smart-contract-escape-hatches/

Источник: bitnovosti.com