Недавний крах DAO – системы на базе Ethereum, из которой хакеры ухитрились увести валюты почти на $150 млн, вызвал серьезную дискуссию. Некоторые из хакеров действительно были злоумышленниками, другие лишь тестировали систему. Но одним из самых важных выводов стало то, что для DAO требуется своего рода аварийный люк. Такой «запасной выход» должен стать тем механизмом, который при обнаружении чего-либо подозрительного будет в состоянии остановить работу умного контракта и перейти на особый уровень контроля безопасности.
Главная проблема с аварийным люком заключается в «автономной» природе умных контрактов. Не в последнюю очередь умные контракты используются из-за их предсказуемости и запрограммированности. Было бы по меньшей мере наивно теперь в спешном порядке «приделать» им аварийный люк, лишив их тем самым основных преимуществ.
Предлагаем рассмотреть в этой статье один простой и вместе с тем эффективный аварийный люк, который практически полностью децентрализован и отвечает всем требованиям DAO.
Наивные решения
С технической точки зрения самый простой аварийный люк – это криптографический ключ, встроенный непосредственно в контракт. Активировать такой запасной люк и перевести контракт в «режим обслуживания» может лишь человек, обладающий разрешением. Таким образом, у владельца ключа возникает возможность отладки и перезапуска контракта с использованием одного и того же ключа. Для аварийного люка такого вида подходит умный контракт с мультиподписью или общий секретный ключ, позволяющий отвергнуть операцию главного контракта по совместному решению владельцев.
Однако владельцы ключей представляют собой слабое звено: они могут вмешиваться в операцию главного контракта DAO ради собственной выгоды, ключи могут быть утеряны либо украдены, или же злоумышленники могут заставить владельцев выдать им ключи. К тому же мало кто согласится нести такую ответственность, когда при определенном стечении обстоятельств можно оказаться под судом. Следовательно, такой аварийный люк применительно к DAO является нежелательным.
Лучший выход
Однако простой в реализации, децентрализованный запасной выход (ДЗВ) существует, с которым атака, опустошившая DAO, вполне могла быть остановлена.
Рассмотрим его структуру подробнее. Итак, в состав ДЗВ входят следующие три компонента.
Буфер. Все деньги на выходе из главного контракта проходят контракт ДЗВ.
ДЗВ сохраняет эти денежные потоки в буфере на заранее определенное количество времени, например сутки, прежде чем фактически выполнить send() – процедуру по их окончательному выводу. Эта задержка обеспечивает возможность рассмотреть операцию главного контракта на предмет ошибок.
Спусковой механизм. ДЗВ имеет механизм, при помощи которого денежные потоки в его буфере при определенных условиях могут быть возвращены в главный контракт.
Действие отмены. Способ, при которым ДЗВ определяет, как вернуть те или иные действия.
Например, если сделка в буфере отменена, средства в полном размере возвращаются участникам сделки.
Внедрение спускового механизма может осуществляться одним из двух способов.
Это может быть программируемый автоматический спусковой механизм. Например, он срабатывает, когда в контракте указаны наличные суммы и адрес для выплаты эфира. Слабым местом такого решения является то, что спусковые механизмы и умные контракты программируются человеком. К тому же, механизм в этом случае потребляет топливо системы («газ»). Хотя не исключено, что это не такая уж большая цена, если речь идет о предотвращении кражи более $50 млн.
Переключение, направляемое коллективным разумом, в свою очередь дает преимущества наблюдения процесса людьми – т.е. выявляет проблемы, которые трудно или вовсе невозможно предотвратить с помощью машинного кода. Коллективный кворум может оказаться эффективным при решении вопроса о платежах в буфере в случае подозрений на мошенническое поведение.
Заметим, что ДЗВ никак не влияет ни на сам платеж, ни на главный контракт. Платежи просто получают период задержки, во время которого возникает возможность их возврата.
Таким образом, работа скрипта ДЗВ будет выражаться в некоторой задержке перед отправкой средств. Таков побочный эффект, возникающий как в распределенной, так и централизованной системе. Платеж подготавливается для выполнения, но не делается доступным для клиентов до тех пор, пока транзакция не покинет ДЗВ. Соответственно, операция считается выполненной только после истечения суток либо иного заранее установленного интервала.
Может ли кто-либо из участников остановить этот скрипт? Нет. Полученный коллективным разумом спусковой механизм для активации аварийного люка будет требовать кворума – это может быть 53 % участников DAO, традиционное большинство (больше 2/3), простое большинство (более 1/2) и т.д.
Вывод
С усилением экосистемы Dapp и дорогостоящими ошибками, которые, возможно, будут его сопровождать, расширения для умных контрактов могут стать весьма актуальны. Рассмотренный в этой статье ДЗВ, являющийся одним из решений по созданию хранилища для предотвращения кражи приватных ключей в Биткоине, вполне может стать одним из таких расширений, поскольку с нашей точки зрения в умных контрактах непременно должно быть реализовано нечто подобное.
