Это работает следующим образом:

1) Пишите контрактные тесты в Solidity.

2) К вашему основному коду контракта прикреплен другой код, называемый контрактом «утверждающей защиты». К нему прилагаются тесты, а также основной код. Он имеет мультиподпись владельцев, способных изменить основной код контракта.

3) При развертывании владельцы не могут изменить основной код контракта.

4) Если «утверждение» не удается, то охранник может заблокировать все запросы к основному коду и позволить владельцам с несколькими подписями вернуться «внутрь», чтобы иметь возможность изменить основной код контракта (или тесты).

5) После исправления (владельцы кода изменили код) assert guard блокирует доступ к изменению кода и снова открывает запросы. Если сбой утверждения происходит снова, процесс повторяется.

6) Это можно комбинировать с относительной или фиксированной блокировкой. Относительный == после каждого исправления, если в течение последующих 6 месяцев не происходит сбоя утверждения, то охранник навсегда окостеневает, становится полностью автономным и ненадежным. Любые новые ошибки утверждения больше не будут вызывать срабатывание защиты. Фиксированная блокировка зависит от времени развертывания. Это не основано на том, обнаружены ли ошибки утверждения. Другими словами: например, через 6 месяцев после развертывания, если был сбой или нет, охранник окостенеет.

Чтобы стимулировать поиск ошибок, можно использовать награды.

Автоматические награды могут быть назначены при обнаружении ошибки утверждения. Если автоматизация кажется несправедливой или потенциально опасной, она может просто зарегистрировать tx.origin и msg.sender, а затем выплатить вознаграждение вручную.

Более демократичное владение кодом должно осуществляться в форме DAO: заинтересованные стороны должны голосовать за то, выглядит ли исправление хорошо (вместо, скажем, мультиподписи трех разработчиков).

Это означает, что (1) можно проводить бета-тестирование живого кода в течение нескольких месяцев, (2) разработчики могут исправлять код в течение этого периода, если он сломается, (3) вам не нужно быть экспертом по Solidity для развертывания функциональных приложений dApp, и (4) через некоторое время он переходит на полностью ненадежную мощь платформы Ethereum.

Этот метод добавляет дополнительную сложность, а также дополнительные затраты и заслуживает обсуждения. Если у вас есть какие-либо мысли, пожалуйста, поделитесь.

Саймон де ла Рувьер, инженер по связям с общественностью в ConsenSys.

Изображение предоставлено: https://goo.gl/8praKt

[1] Награды за неудачные тестовые случаи и утверждения, позволяющие разработчикам вернуться, хотя я не могу вспомнить, где я это читал. Пожалуйста, пингуйте меня, если у вас есть источник.