Виталик последний длинный текст: обзор различных L2

Исходный заголовок：《Разные типы второго уровня》

Исходный автор: Виталик Бутерин

Исходный перевод: BlockBeats

Экосистема быстро расширялась в течение последнего года. Традиционно представленный экосистемой ZK-EVM rollup, такой как StarkNet, Arbitrum, Optimism и Scroll, быстро развивался, постоянно улучшая свою безопасность, а страница L2beat хорошо суммирует состояние каждого проекта.

Кроме того, мы также видим, что некоторые команды строят сайдчейны, а также начинают разрабатывать rollup-решения (например, Polygon), некоторые проекты L1 пытаются развиваться в сторону валидации (например, Celo), а также появляются совершенно новые попытки (например, Linea, Zeth…).

Одним из неизбежных результатов является то, что мы видим, как проекты L2 становятся более гетерогенными (то есть «гетерогенизация». Примечание переводчика: в криптосфере «гетерогенизация» относится к ситуации, когда сосуществуют или смешиваются различные виды или свойства вещей. Этот термин обычно используется для описания различных блокчейнов, протоколов, технологий или активов, которые имеют разные характеристики, правила или свойства). Я ожидаю, что эта тенденция будет продолжаться по следующим причинам:

В настоящее время некоторые независимые проекты L1 стремятся более тесно взаимодействовать с экосистемой Ethereum и могут перейти в проекты L2. Эти проекты могут надеяться на поэтапный переход. Немедленный полный переход снизит доступность, поскольку технологии еще не готовы интегрировать все в rollup-решения. А в более позднем полном переходе может быть потеряна инерция, и не будет времени на значимые изменения.

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

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

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

Важной темой является то, что, хотя приложения и пользователи, находящиеся на Ethereum L1, готовы в краткосрочной перспективе платить небольшие, но все же заметные сборы за rollup, пользователи из не-блокчейн мира менее готовы это делать: если вы ранее платили 1 доллар, то платить 0.10 долларов будет легче воспринимать, а если вы ранее не платили ничего, то это будет трудно воспринимать.

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

Естественный вопрос заключается в том: какой из этих сложных компромиссов между rollup-решениями, validium (валидацией) и другими системами является разумным для конкретного приложения?

Rollups против Validium против Отключенных Систем

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

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

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

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

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

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

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

1. Стоимость нативной доступности данных Ethereum, которая будет снижаться с развитием технологий. Следующий хардфорк Ethereum Dencun вводит EIP-4844 (также известный как «proto-danksharding»), который предоставляет около 32 кБ/с доступности данных на цепи.

Ожидается, что в ближайшие годы, с запуском полного danksharding, эта доступность данных будет постепенно увеличиваться, с конечной целью около 1.3 МБ/с доступности данных. В то же время улучшения в сжатии данных позволят нам реализовать больше функций при том же объеме данных.

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

Этот компромисс примерно выглядит так:

Другим типом, который стоит упомянуть, являются предварительные подтверждения (pre-confirmations). Предварительные подтверждения — это сообщения, подписанные группой участников в rollup или validium, которые указывают: «Мы подтверждаем, что эти транзакции включены в этом порядке, и что корень пост-состояния таков». Эти участники могут подписать предварительное подтверждение, которое не соответствует реальности, но если это так, их депозит будет уничтожен.

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

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

Чтение Ethereum без доверия

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

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

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

Существует два способа решения этой проблемы:

1. Верхняя цепь может читать только окончательно подтвержденные блоки Ethereum, поэтому ей никогда не нужно откатываться;

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

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

Способность блокчейна читать Ethereum без доверия имеет два важных значения:

Во-первых, эта способность может снизить безопасность, связанную с мостами токенов, выпущенными на Ethereum (или других решениях второго уровня), которые должны быть перенесены на эту цепь;

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

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

Может ли наличие моста стать validium?

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

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

На данный момент — нет! Есть две причины:

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

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

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

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

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

1. Разместить в верхней цепи контракт моста, который проверяет окончательно подтвержденные блоки Ethereum;

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

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

Достаточно ли этого? На самом деле, этого недостаточно, поскольку существуют некоторые небольшие крайние случаи:

1. Что произойдет, если Ethereum подвергнется атаке 51%?

2. Как обрабатывать хардфорки обновлений Ethereum?

3. Как обрабатывать хардфорки обновлений вашей цепи?

Атака 51% на Ethereum приведет к последствиям, аналогичным атаке 51% на верхнюю цепь, но наоборот. Хардфорк Ethereum может сделать мосты Ethereum в верхней цепи недействительными. Социальное обязательство (social commitment), что если Ethereum восстановит окончательно подтвержденный блок, он будет восстановлен, а если Ethereum проведет хардфорк, будет проведен хардфорк, является самым чистым способом решения этой проблемы.

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

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

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

Заключение

«Связь с Ethereum» имеет два ключевых измерения:

1. Безопасность вывода на Ethereum;

2. Безопасность чтения Ethereum.

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

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

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

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