Серия «Самостоятельное хранение», часть II

Мотивация

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

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

Контракт приложения StarkEx: обзор

Смарт-контракт приложения StarkEx (ASC) использует шаблон прокси (впервые предложенный openZeplin ) и поэтому имеет несколько подкомпонентов. Прокси-контракт содержит все хранилище и средства, а также имеет адрес (т. е. указатель на) логического контракта, который определяет функциональность. Из прокси-контракта мы вызываем логический контракт, используя вызовы делегатов (которые выполняются в контексте прокси-контракта). Таким образом, логика StarkEx ASC определяется логическим контрактом. Таким образом, логика StarkEx ASC обновляется посредством развертывания нового контракта и обновления указателя в прокси-контракте. Адреса контракта Верификатора и Комитета по доступности данных ( DAC) упоминаются в логическом контракте, а не в прокси-контракте (если вы хотите освежить в памяти различные компоненты StarkEx, вот обзор ).

Механизмы обновления и защита самообслуживания

На этапе I у нас есть отдельный механизм обновления для каждого из этих трех контрактов: Logic, Verifier и DAC. Все операции по обновлению могут выполняться только с разрешенных адресов.

1. Обновление логического контракта:

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

Давайте обсудим оставшиеся контракты, оба из которых предоставляют услугу проверки: один — проверка доказательств STARK (контракт верификатора), а другой — проверка доступности данных (контракт DAC). Они схожи по своей природе, поэтому используются Логическим контрактом и обновляются одинаковым образом.

2. Обновление контракта верификатора :

• Механизм: Логический контракт хранит список контрактов верификатора. Доказательство считается действительным только в том случае, если оно принято всеми верификаторами. Добавление нового верификатора в контракт происходит немедленно. Удаление верификатора блокируется по времени на время upgrade_activation_delay.
• Самостоятельное хранение: цель верификатора - принять действительные доказательства и отклонить недействительные доказательства. Из соображений безопасности мы разрешаем немедленное добавление (без задержки) нового верификатора — обратите внимание, что это немедленное добавление , а не замена. Поскольку доказательство должно быть принято всеми верификаторами, недействительные доказательства по-прежнему не могут быть приняты. Временная блокировка гарантирует, что уже развернутые верификаторы не могут быть удалены немедленно, что позволяет сообществу просмотреть только что добавленный контракт.

3. Модернизация контракта DAC : идентичная модель и аргументация для контрактов Verifier.

Чтобы лучше понять кумулятивный характер этих верификационных контрактов, рассмотрим метафору с ситом: верификатор подобен очень тонкому «решету», которое пропускает только достоверные утверждения. В StarkEx мы не просто заменяем одно «решето» другим, а требуем, чтобы выражение проходило как через уже существующие «решета», так и через новое развернутое «решето». Новое «сито» не может проверить неверный оператор; он может только еще больше ограничить набор утверждений, считающихся действительными. Это, например, именно то, что произошло с большинством обновлений протокола Биткойн, которые были софт-форками: как только софт-форк введен в действие, ранее недействительные блоки остаются недействительными, и до сих пор действительные блоки теперь также могут стать недействительными.

Риски безопасности и их снижение

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

1. Заблокированные средства:

• Риск : пользовательские средства, внесенные в смарт-контракт, могут быть заблокированы из-за ошибки (например, ошибки четности).
• Устранение : добавление новой версии логического контракта, исправляющей ошибку.

2. Украденные средства:

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

3. Ошибка проверки достоверности : этот тип ошибки, который может естественным образом привести к блокировке или краже средств, достоин отдельного обсуждения, поскольку StarkEx — это система на основе zkp.

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

~ Том Брэнд , Лиор Голдберг, Михаил Рябзев