Экосистема Ethereum L2 быстро расширилась за последний год. Накопительная экосистема ZK-EVM, традиционно состоящая из StarkNet, Arbitrum, Optimism и Scroll, быстро развивается и добивается больших успехов в повышении безопасности; страница L2beat хорошо справляется с подведением итогов о состоянии каждого проекта. Кроме того, мы также видели, как команды, создающие сайдчейны, также начали создавать Rollup (Polygon), проекты L1, стремящиеся развиваться в направлении проверки достоверности (Celo), и другие совершенно новые попытки (Linea, Zeth...).
Неизбежным результатом этого является то, что мы видим, что проекты L2 демонстрируют тенденцию к увеличению гетерогенности. Я ожидаю, что эта тенденция сохранится по нескольким основным причинам:
Некоторые проекты, которые в настоящее время являются независимыми L1, стремятся приблизиться к экосистеме Ethereum и потенциально стать L2. Эти проекты, возможно, захотят постепенного перехода. Одновременный переход сейчас снизит удобство использования, поскольку технология не готова объединить все в один пакет. Если вы сделаете одноразовый переход позже, вы рискуете пожертвовать импульсом и сделать это слишком поздно, чтобы иметь смысл.
Некоторые централизованные проекты хотят предоставить пользователям больше гарантий безопасности и изучают подходы на основе блокчейна. Во многих случаях в предыдущую эпоху эти проекты исследовали «разрешенные цепочки консорциумов». Фактически, им может потребоваться только «полуцентрализованный» уровень децентрализации. Более того, поскольку их пропускная способность обычно очень высока, они даже не подходят для разработки Rollup, по крайней мере, в краткосрочной перспективе.
Нефинансовые приложения, такие как игры или социальные сети, хотят быть децентрализованными, но требуют только «полуцентрализованного» уровня безопасности. Когда дело доходит до социальных сетей, реальность такова, что к различным частям приложения нужно относиться по-разному: редкие и ценные действия, такие как регистрация имени пользователя и восстановление учетной записи, следует выполнять в Rollup, но частые и малоценные действия, такие как публикации и опросы не снижают уровень безопасности. Если из-за сбоя ссылки ваш пост исчезнет, это приемлемая цена. Если цепочка выходит из строя и ваша учетная запись потеряна, проблема намного серьезнее.
Важная тема заключается в том, что в то время как приложения и пользователи, которые в настоящее время используют Ethereum L1, смогут платить меньшие, но все же видимые комиссионные за объединение в краткосрочной перспективе, пользователи из мира, не связанного с блокчейном, не могут: если вы ранее платили 1 доллар, то платить 0,1 доллара будет больше. разумнее, чем платить 0 долларов. Это относится как к текущим централизованным приложениям, так и к более мелким приложениям L1, которые обычно взимают очень низкую плату, но по-прежнему имеют небольшую базу пользователей.
Естественно возникает вопрос: какой из этих сложных компромиссов между объединением, достоверностью и другими системами является разумным для данного приложения?
Rollup, Validiums, Disconnected Systems
Первое измерение безопасности и масштаба, которое мы хотим изучить, можно описать следующим образом: если у вас есть актив, выпущенный на уровне L1, а затем внесенный в L2, а затем переданный вам, какую гарантию вы можете дать, чтобы вы могли передать его? этот актив? Вернуть L1?
Возникает параллельный вопрос: какой выбор технологии приводит к такому уровню уверенности и каковы компромиссы этого выбора технологии?
Мы можем использовать диаграмму, чтобы описать это просто:
Стоит отметить, что это упрощенный режим со множеством промежуточных опций. Например:
Между объединением и валидием: в валидии любой может совершать внутрисетевые платежи для покрытия комиссий за транзакции, после чего операторы будут вынуждены предоставить цепочке некоторые данные или потерять свои депозиты.
Между Plasma и валидием: система Plasma предоставляет гарантии безопасности, аналогичные Rollup, обеспечивая при этом доступность данных вне цепочки, но может поддерживать только ограниченные приложения. Система может обеспечить полную EVM и предоставить гарантии уровня Plasma для пользователей, которые не используют эти более сложные приложения, и гарантии уровня валидия для пользователей, которые это делают.
Эти промежуточные параметры можно рассматривать как диапазон между сводными и действительными значениями. Но что побуждает приложение выбирать точку спектра, а не точку левее или правее? Есть два основных фактора:
1. По мере развития технологий стоимость доступности собственных данных в Ethereum будет постепенно снижаться. Следующий хард-форк Ethereum, Dencun, представляет EIP-4844 (также известный как «родной форк»), который обеспечивает доступность данных в цепочке примерно на 32 КБ в секунду. Ожидается, что в течение следующих нескольких лет доступность данных будет поэтапно увеличиваться с внедрением полного «шардинга данных по цепочке», в конечном итоге достигнув уровня доступности данных примерно 1,3 МБ в секунду. В то же время усовершенствования в технологии сжатия данных позволят нам делать больше с тем же объемом данных.
2. Потребности самого приложения: насколько пользователи пострадают от высоких комиссий и сколько это будет стоить, если приложение пойдет не так? Финансовые приложения больше страдают от сбоев приложений; игры и социальные сети требуют большого количества действий на пользователя и относительно малоценных действий, поэтому для них оправданы различные компромиссы в области безопасности.
Компромиссы выглядят примерно так:
Еще один тип частичной гарантии, о котором стоит упомянуть, — это предварительное подтверждение. Предварительное подтверждение — это сообщение, подписанное группой сторон в течение периода объединения или действия, в котором говорится: «Мы подтверждаем, что эти транзакции включены в этот заказ и что корень после состояния является таковым». Возможно, что подписанные этими участниками предварительные подтверждения не будут соответствовать последующей реальности, но в противном случае депозит будет уничтожен. Это полезно для приложений с низкой стоимостью, таких как потребительские платежи, в то время как приложения с высокой стоимостью, такие как переводы средств на несколько миллионов долларов, возможно, должны ждать «регулярных» подтверждений с полной поддержкой безопасности со стороны системы.
Предварительную проверку можно рассматривать как еще один пример гибридной системы, похожей на упомянутую выше «гибридную систему плазмы/валидиума», но на этот раз с полной безопасностью, но с более высокой задержкой (или валидием) и низкими уровнями безопасности. Гибрид между системами с гораздо более высокая задержка, но меньшая задержка. Приложения, которым требуется меньшая задержка, получат меньшую безопасность, но могут жить в той же экосистеме, что и приложения, которые допускают более высокую задержку в обмен на максимальную безопасность.
Читайте Ethereum без доверия
Другая менее продуманная, но все же очень важная форма подключения связана со способностью системы читать блокчейн Ethereum. В частности, это включает в себя возможность восстановления после восстановления Ethereum. Чтобы понять ценность этого, рассмотрим следующую ситуацию:
Предположим, что цепочка Ethereum откатывается, как показано на рисунке. Это может быть временный сбой в эпоху, когда цепочка не была завершена; это также может быть период утечки бездействия, когда слишком много валидаторов находятся в автономном режиме, а цепочка не была завершена в течение длительного времени;
Наихудший сценарий, который может возникнуть, выглядит следующим образом:
Предположим, что первый блок верхней цепочки считывает некоторые данные из крайнего левого блока цепочки Ethereum. Например, кто-то на Ethereum вносит 100 ETH в топ-чейн. Затем Эфириум откатился. Однако верхняя цепь не будет откачена. Таким образом, будущие блоки верхней цепочки будут правильно следовать за новыми блоками из новой правильной цепочки Ethereum, но последствия неправильной старой ссылки (т. е. депозита в 100 ETH) теперь все еще являются частью верхней цепочки. Эту уязвимость можно использовать для печати денег, превращая мостовой ETH в верхней цепочке в частичный резерв.
Есть два пути решения этой проблемы:
1. Топчейн может читать только последний блок Эфириума, поэтому его никогда не нужно восстанавливать.
2. Если Ethereum будет восстановлен, топчейн также может быть восстановлен. Оба метода позволяют избежать этой проблемы. Первое проще реализовать, но оно может привести к длительной потере функциональности, если Ethereum вступит в период неактивной утечки. Последнего добиться сложнее, но он всегда обеспечивает оптимальную функциональность.
Обратите внимание, что (1) имеет крайний случай. Если атака 51% на Ethereum создает два несовместимых новых блока, и оба блока оказываются одновременно, то верхняя цепочка, скорее всего, заблокирует неправильный блок (т. е. социальный консенсус Ethereum в конечном итоге не поддерживает блок) и ее необходимо восстановить. в правильный блок. Возможно, нет необходимости заранее писать код, чтобы справиться с этой ситуацией; просто сделайте хард-форк верхней цепочки.
Есть две причины, по которым цепочка может читать Ethereum без доверия:
1. Это уменьшает проблемы безопасности, связанные с подключением токенов, выпущенных на Ethereum (или другом L2), к этой цепочке;
2. Это позволяет кошелькам абстракции учетных записей использовать архитектуру хранения общих ключей для безопасного хранения активов в цепочке.
Первый пункт важен, хотя его необходимость уже широко признана. Второй момент также важен, поскольку означает, что у вас может быть кошелек, который позволяет легко менять ключи и хранить активы в большом количестве различных цепочек.
Владение мостом делает его действительным?
Допустим, топ-чейн начинался как отдельная цепочка, а затем кто-то добавил мостовой контракт на Ethereum. Мостовой контракт — это простой контракт, который принимает заголовок блока из верхней цепочки, проверяет, что любой заголовок блока, отправленный ему, содержит действительный сертификат, указывающий, что он был принят консенсусом верхней цепочки, и добавляет этот заголовок блока в список. середина. На этой основе приложения могут реализовывать такие функции, как ввод и вывод монет. Как только такой мост будет создан, сможет ли он обеспечить гарантию безопасности активов, о которой мы упоминали ранее?
Пока еще нет! Есть две причины:
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 в топ-чейне перестанет действовать. Самый простой способ решить эту проблему — взять на себя социальное обязательство восстановить последний блок, если Ethereum восстановит его, а также взять на себя социальное обязательство провести хард-форк в случае хард-форка Ethereum; Такое обещание, возможно, никогда не потребуется выполнять на самом деле: вы можете заставить гаджет управления в верхней цепочке включиться, когда он увидит доказательства возможной атаки или хард-форка, и выполнить хард-форк верхней цепочки только в случае сбоя гаджета управления.
К сожалению, единственный возможный ответ на пункт (3) — это установка какого-либо устройства управления в Ethereum, которое информирует мостовой контракт на Ethereum о хард-форк-обновлениях топ-чейна.
Резюме: Моста двусторонней проверки почти достаточно для создания валидума блокчейна. Основным оставшимся фактором является социальное обязательство: если с Эфириумом произойдет что-то особенное, что приведет к тому, что мост перестанет работать, другая цепочка в ответ произведет хардфорк.
в заключение
Есть два ключевых аспекта «подключения к Ethereum»:
1. Безопасность вывода средств на Ethereum;
2. Прочтите безопасность Эфириума.
Все это важно и имеет разные соображения. В обоих случаях существует непрерывный спектр:
Обратите внимание, что каждое из этих двух измерений измеряется двумя разными способами (так действительно ли существует четыре измерения?): Безопасность вывода средств может быть измерена (i) уровнем безопасности и (ii) получением выгоды от самого высокого уровня безопасности. Измеряется как процент пользователей или вариантов использования; безопасность чтения может быть измерена по (i) тому, насколько быстро цепочка считывает блоки Ethereum, особенно финальные блоки, по сравнению с любыми блоками, и (ii) насколько быстро цепочка справляется с атаками 51% и жесткими оценками. и другие крайние случаи для измерения силы социальной приверженности.
Ценность проекта проявляется во многих областях этого дизайнерского пространства. Для некоторых приложений очень важны высокая безопасность и тесная связь. Для других приложений допустимо быть более свободным, чтобы добиться более высокой масштабируемости. Во многих случаях лучшим вариантом может быть начать с более слабой связи сегодня и перейти к более жесткой связи в течение следующего десятилетия по мере развития технологий.
