Узнайте больше о том, зачем Rollups нужен комитет по безопасности?

АВТОР ОРИГИНАЛА: ПАТРИК МАККОРРИ

Оригинальная подборка: Луффи, Foresight News

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

• Аудит в режиме реального времени
• Справка о платежеспособности по умолчанию
• Депонирование пользовательских средств не является обязательным
• Честный участник вечеринки защищает всю систему

Самое главное, что все усилия по проектированию и внедрению Rollup сосредоточены на защите пользователей, их средств и всех их взаимодействий от потенциально неизвестных и могущественных системных операторов.

Даже если вся система находится в автономном режиме, пользователи могут восстановить свои средства самостоятельно.

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

Требуется много усилий, чтобы заставить свертку работать правильно.

А как насчет мультиподписей?

Звучит неплохо, но вся система в конечном итоге управляется мультиподписью. Если подписант скомпрометирован или злонамеренен, то он может легко украсть все средства.

Итак, кого волнуют роллапы? где-нибудь на CT.

Это правда, что все текущие роллапы имеют мультиподпись и имеют право обновлять базовый смарт-контракт, но, как мы увидим, это консервативный механизм, который защищает средства пользователей и является частью более широкой системной архитектуры.

Обязанности Комитета по безопасности

Мультиподпись — это технический термин, относящийся к системе, которая требует, чтобы несколько подписывающих сторон авторизовали действие. Например, K из N подписантов заполняют цифровую подпись для того, чтобы транзакция была разрешена.

В контексте роллапов мультиподпись часто называют комитетом безопасности, где подписантам предоставляются полномочия по обновлению всех связанных смарт-контрактов.

Давайте взглянем на Совет Безопасности в Arbitrum (поскольку я с ним хорошо знаком), чтобы получить представление о типах обязанностей, которые могут быть у этой организации:

*Вето. Если Комитет по безопасности считает, что предложение, принятое Arbitrum DAO, нарушает устав Arbitrum и может нанести вред экосистеме Arbitrum, он может отменить предложение. Например, отменить предложение, которое прошло из-за атаки на систему управления. *Обслуживания. Обновите пакет смарт-контрактов Arbitrum, чтобы внести незначительные изменения, которые менее значимы и не требуют участия Arbitrum DAO. *Чрезвычайных ситуаций. Быстро реагируют в случае чрезвычайной ситуации, а если считают, что средства пользователей находятся под неминуемым риском, могут срочно обновить смарт-контракт.

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

Члены комитета по безопасности должны быть очень надежными людьми.

Существует уверенность в том, что подписанты смогут быстро отреагировать, смогут обновить смарт-контракт в случае чрезвычайной ситуации и сделают все возможное, чтобы сохранить средства в смарт-контракте в безопасности.

Выберите правильный порог мультиподписи

Есть два важных фактора, которые следует учитывать при принятии решения о создании комитета по безопасности:

• Сколько подписантов?
• Каково минимальное количество подписантов, необходимое для одобрения действия?
• Это может показаться тривиальным вопросом, в конце концов, это всего лишь два числа, но есть баланс, который необходимо учитывать:
• Нарушение безопасности: участники K могут вступить в сговор с целью изменения смарт-контрактов и кражи средств пользователей.
• Активное нарушение: участники N-K+ 1 вступают в сговор, чтобы предотвратить любые изменения в смарт-контракте, особенно если обнаружена критическая уязвимость.

Задача состоит в том, чтобы установить пороговое значение, которое позволит сохранить средства в безопасности в мирное время и быстро действовать в случае чрезвычайной ситуации, когда средства пользователей находятся под угрозой.

Рассмотрим на конкретном примере. Допустим, установлено пороговое значение 9/10, при котором 9 подписывающих сторон должны подписать сообщение. Это строгий порог безопасности, так как 9 подписантов должны вступить в сговор, чтобы украсть средства. Недостатком, однако, является то, что любые две подписанты могут заблокировать любое действие в чрезвычайной ситуации. Например, если две подписанты отправятся далеко друг от друга трансатлантическим рейсом, Комитет по безопасности не сможет выполнять свои обязанности.

Конечно, если порог безопасности низкий, скажем, 2/10, то для кражи средств пользователя достаточно вступить в сговор (или закрытый ключ скомпрометирован).

Восприятие целостности человека, скорее всего, изменится со временем

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

Член Комитета по безопасности

Основной роллап мгновенно повышает порог мультиподписи, необходимый для всех смарт-контрактов

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

• Стадия разработки роллапа,
• Для защиты личной безопасности участников,
• Считаем, что анонимность является лучшим вариантом защиты средств пользователей.
• С другой стороны, есть три проекта Rollup, которые публично объявили о своем членстве в комитете безопасности:
• Arbitrum: Подписанты избираются публично, и текущий список можно посмотреть на Tally. С проектом Arbitrum связаны только три подписанта (двое из Offchain Labs и один из Arbitrum Foundation).
• База: 2/2 мультиподписи, одна из которых контролируется Базой, а другая — Оптимизмом.
• Polygon zkEVM: Еще не реализован, но они объявили, что они обновят свою мультиподпись до 10/13, которая включает в себя двух членов из Polygon Labs и одного консультанта из Polygon Labs.
• zkSync Lite: zkSync Lite следует отличать от ZkSync Era, чей комитет по безопасности публично объявлен и не включает прямых аффилированных лиц из проекта Rollup (за исключением инвесторов в zkSync).

В Arbitrum и в готовящемся к выпуску Polygon только несколько подписантов напрямую связаны с проектом Rollup, и их число достаточно мало, чтобы гарантировать, что аффилированные лица не смогут вступить в сговор с целью заблокировать действия, предпринятые Комитетом по безопасности. В zkSync Lite, помимо инвесторов zkSync, назначают подписантов, которые не зависят от проекта.

Во всех случаях Rollup придает большое значение подписывающим сторонам, которые не имеют прямого отношения к проекту.

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

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

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

P.S. Шесть членов Комитета по безопасности Arbitrum в настоящее время предварительно назначены, но они будут заменены на мартовских выборах.

Ослабить полномочия Комиссии

До сих пор мы рассматривали только один комитет, который имеет право немедленно обновить смарт-контракт, но есть способы ограничить полномочия комитета:

Задержка по времени. Все действия, санкционированные Комиссией, не будут выполнены и вступят в силу до истечения времени T.

Только пауза. Все активы, принадлежащие нативному кроссчейн-мосту, могут быть заморожены комитетом. Это может привести к приостановке работы следующих функций:

• Доставить сообщение с L2 на L1 (т.е. вывести деньги),
• Завершить сортировку отложенных транзакций,
• Заполнение новых контрольно-пропускных пунктов/сертификатов,
• Принимать новые данные свертки (т.е. ожидающие транзакции).

Обход комиссии (удалено). Откажитесь от комитета и положитесь на другой механизм управления, например DAO, для утверждения обновления.

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

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

Например, CVE-2018-17144 в BTC изначально рекламировалась как DDoS-уязвимость в попытке скрыть более серьезную уязвимость инфляции токенов. Скорость обновления имеет решающее значение для предотвращения его использования.

Оценка защитных механизмов только паузы

Рассмотрим потенциальный сценарий активной эксплуатации уязвимости злоумышленником:

• Вредоносные L2 → L1 сообщения. Злоумышленник может создавать произвольные сообщения, исходящие из смарт-контракта на роллапе, и пересылать сообщение смарт-контракту на ETH через собственный кроссчейн-мост.
• Недопустимые переходы между состояниями. Злоумышленник может выполнить транзакцию на свертке, которая нарушает правила функции перехода состояния и, как правило, должна считаться недействительной.
• Лазейки для вывода средств. Злоумышленник может вывести средства с нативного кроссчейн-моста, просто оформив транзакцию на ETH Fang (уровень 1).

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

Мы оценим только возможность приостановки работы системы и степень, в которой система может быть приостановлена.

В случае вредоносных сообщений L2 → L1 функция паузы может смягчить атаку, не мешая торговой деятельности. Комитет должен приостановить обмен сообщениями и/или доработать функциональность новых контрольно-пропускных пунктов. Существует аргумент, что перед выполнением сообщения L2 → L1 должна быть временная задержка, чтобы у комитета было время обнаружить ошибки и отреагировать на чрезвычайные ситуации.

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

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

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

Это связано с тем, что некоторые системы, такие как быстрые кроссчейн-мосты, которые переводят средства из одного роллапа в другой, могут санкционировать перевод средств, как только они считают, что транзакции роллапа (включая недействительные транзакции) отсортированы. В этом примере он может позволить злоумышленнику использовать протокол DeFi на Rollup, а затем быстро перевести средства, переведя их на другой Rollup через быстрый кроссчейн-мост.

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

Наконец, если уязвимость позволяет злоумышленнику выводить средства напрямую с нативного кроссчейн-моста, аналогично Nomad Hack, комитет безопасности может оказаться бессильным остановить ее.

В конечном счете, существует всеобъемлющая проблема с механизмом подвески. Мы должны исходить из того, что существует более широкая система управления, которая может утверждать обновления и повторно активировать накопительные пакеты. Если предположить, что система управления представляет собой DAO с системой голосования в сети, работающей на Rollup, то возникают сложные вопросы реализации.

Например, если кроссчейн-мост сообщений L2→L1 приостановлен, результаты голосования DAO не могут быть переданы из роллапа в нативный кроссчейн-мост на ETH, и у DAO должен быть альтернативный способ отправить одобрение и выполнить обновление.

Постепенный роспуск Совета Безопасности

В сообществе есть те, кто считает, что комитет по безопасности должен быть ликвидирован, но, на мой взгляд, это порождает две проблемы:

Ложное чувство безопасности. Злоумышленники, знающие об эксплойте, ждут, пока комитет по безопасности не будет выведен из строя, прежде чем выполнить атаку. Со временем это может подорвать нашу уверенность в безопасности наших систем.

Возможности восстановления ограничены. Без комитета по безопасности сообщество не сможет дать отпор нападающим. Единственный возможный вариант — запустить параллельный белый взлом и, надеюсь, вернуть часть средств.

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

Имея это в виду, вопрос дизайна должен быть следующим:

Как мы можем заставить комитет по безопасности приостановить работу системы с минимальными последствиями для пользователей, в то же время позволив более широкому сообществу участвовать в принятии решений о том, как исправить ошибки и повторно активировать систему?

Другими словами, нам нужна программа, которая действительно позволит сообществу вмешаться и восстановить систему, а затем ограничить полномочия Совета Безопасности по приостановке работы.

В пространстве блокчейна уровня 1 с сообществом действительно можно связаться напрямую, используя активируемые пользователем форки, но этот метод не работает для смарт-контрактов на ETH квадратах (таких как Rollups), потому что нет необходимости форковать весь ETH. В некоторых случаях сообщество ETH может коллективно принять решение о сохранении Rollup, как TheDAO в 2016 году, но Rollup никогда не должен полагаться или ожидать такого результата.

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

Как упоминалось ранее, если Rollup делегирует свою безопасность DAO, то должна быть реализация, которая позволяет DAO голосовать непосредственно за ETH. Это очень сложно, особенно если протокол голосования существует в Rollup.

Наконец, я считаю, что необходимо провести всесторонний обзор типов ситуаций, которые могут потребовать ответа со стороны Совета, с тем чтобы облегчить дискуссию о его необходимости.

Зачем беспокоиться о роллапах, если у вас есть мультиподписи?

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

Является ли Rollup просто мультиподписью?

Мой ответ – нет.

Чтобы понять, почему, лучше всего сделать шаг назад и понять, что на самом деле хочет сделать блокчейн-система.

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

Имея это в виду, любая блокчейн-система состоит из двух компонентов:

• Блокчейн-протокол. Сочетание программного обеспечения, криптографии и распределенных систем дает любому человеку уверенность в целостности базы данных.
• Система управления. Координационный механизм, который позволяет всем заинтересованным сторонам работать вместе и согласовывать изменения в протоколе блокчейна.

Цель любой блокчейн-системы, включая Rollup, состоит в том, чтобы гарантировать, что протокол блокчейна всегда работает с чрезвычайно надежным временем безотказной работы 99,9999%. Доверенный системный оператор практически не должен вмешиваться в повседневную работу системы. В конечном счете, именно программное обеспечение, криптография и распределенные системы в конечном итоге несут ответственность за защиту балансов пользователей, кода смарт-контрактов и состояния.

Иногда необходимо изменить протокол блокчейна, чтобы улучшить интересы пользователей. Сообщество может захотеть исправить проблемы конфигурации, добавить новые функции или отреагировать на критические уязвимости, угрожающие целостности системы. Это требует вмешательства человека и может быть вызвано только в 0,0001% случаев.

Системы управления отвечают за осуществление вмешательства человека, и за последние годы появилось несколько подходов:

• Тоталитарные политические партии: Односторонние партии могут самостоятельно решать, как модернизировать систему (многие проекты, в том числе и BTC, начинались именно таким образом). • Приблизительный консенсус: Большинство участников заявили, что они готовы развернуть обновление, определить день отметки, а затем выполнить обновление в день отметки (BTC/ETH).

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

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

Совет Безопасности не прекращает нападение. Это пассивный механизм, который работает вместе с управлением, когда средства пользователей протокола блокчейна или надежность/производительность системы подвергаются атаке.

В заключение

Все дискуссии вокруг блокчейн-протоколов, управления и комитетов по безопасности имеют решающее значение. Существование этой дискуссии — это то, что делает криптовалюты такими особенными.

Это хороший пример инженерии доверия: инженерной дисциплины, которая фокусируется на выявлении, измерении и уменьшении/устранении элементов доверия в системе.

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

Вот почему члены сообщества скептически относятся к роли комитета по безопасности, но они несут ответственность за то, чтобы придумывать лучшие решения во время чрезвычайных ситуаций для защиты средств пользователей реактивным образом.

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