Различные типы уровней 2

Особая благодарность Карлу Флоршу за отзывы и рецензию

Экосистема Ethereum второго уровня стремительно развивалась в течение последнего года. Экосистема EVM rollup, традиционно включающая Arbitrum, Optimism и Scroll, а в последнее время - Kakarot и Taiko, быстро развивается, делая большие успехи в улучшении безопасности; на странице L2beat хорошо описано состояние каждого проекта. Кроме того, мы видим, как команды, создающие сайдчейн, также начинают создавать роллапы(Polygon), проекты первого уровня стремятся стать валидными(Celo), а также совершенно новые проекты(Linea, Zeth...). Наконец, существует экосистема не только EVM: "почти-EVM", такие как Zksync, расширения, такие как Arbitrum Stylus, и более широкие усилия, такие как экосистема Starknet, Fuel и другие.

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

• Некоторые проекты, которые в настоящее время являются независимыми уровнями 1, стремятся приблизиться к экосистеме Ethereum и, возможно, стать уровнями 2. В этих проектах, скорее всего, потребуется поэтапный переход. Переход на все сразу сейчас приведет к снижению удобства использования, так как технология еще не готова к тому, чтобы вывести все в рулон. Переход сразу на все более поздние этапы чреват тем, что Вы потеряете темп и опоздаете, чтобы стать значимым.
• Некоторые централизованные проекты хотят дать своим пользователям больше гарантий безопасности и изучают способы, основанные на блокчейне, чтобы сделать это. Во многих случаях речь идет о проектах, которые в предыдущую эпоху рассматривали бы "разрешенные цепочки консорциумов". Реалистично, им, вероятно, нужен только "" уровень децентрализации. Кроме того, их часто очень высокая пропускная способность делает их непригодными даже для рулонов, по крайней мере, в краткосрочной перспективе.
• Нефинансовые приложения, такие как игры или социальные сети, хотят быть децентрализованными, но нуждаются лишь в полусреднем уровне безопасности. В случае с социальными сетями это реалистично предполагает разное отношение к разным частям приложения: редкие и высокоценные действия, такие как регистрация имени пользователя и восстановление учетной записи, должны выполняться в режиме развертывания, а частые и малоценные действия, такие как посты и голосования, требуют меньшей безопасности. Если из-за поломки цепи Ваш пост исчезнет, это приемлемая цена. Если из-за сбоя в цепочке Вы потеряете свой аккаунт, это уже гораздо большая проблема.

Основная тема заключается в том, что если приложения и пользователи, работающие сегодня на первом уровне Ethereum, будут прекрасно платить меньшие, но все же заметные сборы за сворачивание в краткосрочной перспективе, то пользователи из мира, не связанного с блокчейном, не будут: легче оправдать уплату $0,10, если раньше Вы платили $1, чем если раньше Вы платили $0. Это относится как к приложениям, которые сегодня являются централизованными, так и к небольшим компаниям первого уровня, которые обычно имеют очень низкую плату, пока их пользовательская база остается небольшой.

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

Роллапы vs валиды vs отсоединенные системы

Первое измерение соотношения безопасности и масштаба, которое мы будем исследовать, можно описать следующим образом: если у Вас есть актив, который был выпущен на L1, затем помещен на депозит L2, а затем передан Вам, какой уровень гарантии у Вас есть, что Вы сможете вернуть актив обратно на L1?

Существует также параллельный вопрос: каков выбор технологии, который приводит к такому уровню гарантии, и каковы компромиссы этого выбора технологии?

Мы можем описать это с помощью графика:

https://s3.ap-northeast-1.amazonaws.com/gimg.gateimg.com/learn/b05ca283dcc74f262ac7a71f340dc85fb3a13b11.png

Стоит отметить, что это упрощенная схема, и существует множество промежуточных вариантов. Например:

• Между rollup и validium: validium, где любой желающий может сделать внутрицепочечный платеж, чтобы покрыть расходы на комиссию за транзакции, и в этот момент оператор будет вынужден предоставить некоторые данные в цепь, иначе он потеряет депозит.
• Между плазмой и валидиумом: система Plasma предлагает гарантии безопасности, подобные rollup, и доступность данных вне цепи, но она поддерживает только ограниченное число приложений. Система может предлагать полный EVM и предлагать гарантии уровня Plasma для пользователей, которые не используют эти более сложные приложения, и гарантии уровня validium для пользователей, которые их используют.

Эти промежуточные варианты можно рассматривать как находящиеся в спектре между рулоном и валидом. Но что побуждает приложения выбирать определенную точку на этом спектре, а не какую-то более левую или более правую? Здесь есть два основных фактора:

1. Стоимость доступности собственных данных Ethereum, которая со временем будет снижаться по мере совершенствования технологии. Следующий хард форк Ethereum, Dencun, представляет EIP-4844 (он же "proto-danksharding"), который обеспечивает ~32 кБ/сек доступности данных на цепи. Ожидается, что в течение следующих нескольких лет этот показатель будет поэтапно увеличиваться по мере внедрения полного данкшардинга, и в итоге доступность данных составит ~1,3 МБ/с. В то же время, усовершенствования в области сжатия данных позволят нам делать больше с тем же объемом данных.
2. Собственные потребности приложения: насколько сильно пользователи пострадают от высокой платы, а не от того, что что-то в приложении пойдет не так? Финансовые приложения больше потеряют от сбоев в работе приложений; игры и социальные сети предполагают много активности на одного пользователя и относительно низкую стоимость, поэтому для них имеет смысл использовать другой компромисс безопасности.

Приблизительно этот компромисс выглядит следующим образом:

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

Предварительное подтверждение можно рассматривать как еще один пример гибридной системы, похожей на гибрид "plasma / validium", упомянутый выше, но на этот раз гибридизирующей между rollup (или validium), имеющей полную безопасность, но высокую задержку, и системой с гораздо более низким уровнем безопасности, имеющей низкую задержку. Приложения, которым нужна меньшая задержка, получают меньшую безопасность, но могут жить в той же экосистеме, что и приложения, которых устраивает большая задержка в обмен на максимальную безопасность.

Доверительное чтение Ethereum

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

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

Наихудший сценарий, который может возникнуть в результате этого, следующий. Предположим, что первый блок из верхней цепочки считывает некоторые данные из самого левого блока в цепочке Ethereum. Например, кто-то на Ethereum вносит 100 ETH в верхнюю цепочку. Затем Ethereum возвращается назад. Однако верхняя цепочка не возвращается. В результате будущие блоки верхней цепочки корректно следуют за новыми блоками из новой корректной цепочки Ethereum, но последствия теперь уже ошибочного старого звена (а именно, депозита в 100 ETH) по-прежнему остаются в верхней цепочке. Этот эксплойт может позволить печатать деньги, превращая мостовой ETH на верхней цепочке в дробный резерв.

Есть два способа решить эту проблему:

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

Обратите внимание, что в (1) есть один крайний случай. Если в результате атаки на 51% Ethereum будут созданы два новых несовместимых блока, которые окажутся завершенными одновременно, то верхняя цепочка вполне может заблокировать не тот из них (т.е. тот, которому социальный консенсус Ethereum в конечном счете не благоприятствует), и придется вернуться, чтобы переключиться на правильный вариант. Пожалуй, нет необходимости писать код для обработки этого случая заранее; его можно просто обработать, выполнив хардфорк верхней цепочки.

Способность цепочки беспрепятственно считывать Ethereum ценна по двум причинам:

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

Делает ли наличие моста Вас валидолом?

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

Пока еще нет! По двум причинам:

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

Теперь давайте сделаем мост проверяющим: он будет проверять не только консенсус, но и ZK-SNARK, доказывающий, что состояние любого нового блока было вычислено правильно.

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

Однако мы все еще не решили вторую проблему: верхняя цепочка не может читать Ethereum.

Для этого нам нужно сделать одну из двух вещей:

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

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

Достаточно ли этого? Как выяснилось, по-прежнему нет, из-за нескольких небольших крайних случаев:

1. Что произойдет, если Ethereum будет атакован на 51%?
2. Как Вы справляетесь с обновлениями Ethereum hard fork?
3. Как Вы справляетесь с хард-форком обновлений Вашей цепи?

Атака на 51% Ethereum приведет к тем же последствиям, что и атака на 51% верхней цепочки, но в обратном порядке. Жесткая развилка Ethereum может привести к тому, что мост Ethereum внутри верхней цепочки перестанет действовать. Социальное обязательство возвращаться, если Ethereum отменяет завершенный блок, и делать хардфорк, если Ethereum делает хардфорк, - это самый чистый способ решить эту проблему. Такое обязательство, вполне возможно, никогда не нужно будет выполнять: Вы можете попросить гаджет управления на верхней цепочке активироваться, если он видит доказательство возможной атаки или хард форка, и выполнять хард форк верхней цепочки только в том случае, если гаджет управления не сработает.

Единственный приемлемый ответ на вопрос (3) - это, к сожалению, наличие в Ethereum некоего устройства управления, которое может заставить мостовой контракт на Ethereum знать о хардфорках верхней цепочки.

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

Выводы

Существует два ключевых аспекта связи "с Ethereum":

1. Безопасность вывода средств в Ethereum
2. Безопасность чтения Ethereum

Они оба важны, но имеют разные аспекты. В обоих случаях существует спектр:

Обратите внимание, что оба измерения имеют два различных способа измерения (так что на самом деле их четыре?): безопасность вывода средств можно измерить (i) уровнем безопасности и (ii) тем, какой процент пользователей или сценариев использования выигрывает от самого высокого уровня безопасности, а безопасность чтения можно измерить (i) тем, насколько быстро цепочка может читать блоки Ethereum, особенно финализированные блоки по сравнению с любыми блоками, и (ii) силой социальных обязательств цепочки по обработке крайних случаев, таких как атаки 51% и жесткие форки.

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

Отказ от ответственности：

1. Эта статья перепечатана из[Виталик Бутерин]. Все авторские права принадлежат оригинальному автору [Виталику Бутерину ]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.