! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
Особая благодарность Карлу Флоершу за отзыв и обзор
Экосистема Ethereum Layer 2 быстро расширялась в течение последнего года. Экосистема ZK-EVM Rollup, представленная StarkNet, Arbitrum, Optimism и Scroll, добилась больших успехов в улучшении безопасности, а на странице L2beat представлена хорошая сводка о статусе каждого проекта. Кроме того, мы видели, как некоторые команды, создающие сайдчейны, начали создавать роллапы (Polygon), некоторые проекты уровня 1 пытались перейти на валидацию (Celo) и предпринимали новые усилия (Linea, Zeth и т. д.).
В результате проекты уровня 2 становятся все более неоднородными. Я ожидаю, что эта тенденция сохранится по следующим причинам:
Некоторые в настоящее время автономные проекты уровня 1 стремятся приблизиться к экосистеме Ethereum и потенциально стать уровнем 2. ** Эти проекты могут потребовать постепенного перехода. Переход сейчас приведет к снижению удобства использования, потому что технология не готова поместить все на роллап; Но слишком позднее переключение может стоить импульса и слишком поздно, чтобы иметь какой-либо смысл.
Некоторые централизованные проекты хотят предоставить пользователям больше гарантий безопасности и изучают возможности на основе блокчейна. Во многих случаях эти проекты могут ранее исследовать «цепочки разрешенных консорциумов». На самом деле, им может понадобиться только «средний уровень» децентрализации. Кроме того, они часто имеют очень высокую пропускную способность, что делает их непригодными даже для свертки, по крайней мере, в краткосрочной перспективе.
Нефинансовые приложения, такие как игры или социальные сети, хотят быть децентрализованными, но нуждаются только в «среднем уровне» безопасности. Социальные сети, например, на самом деле по-разному обрабатывают разные части приложения: низкочастотные, но важные действия, такие как регистрация имени пользователя и восстановление учетной записи, должны выполняться на Rollup; Высокочастотные и малоценные действия, такие как публикация и опрос, требуют меньше безопасности. Если ваш пост исчезает из-за сбоя цепочки, это приемлемая цена; Но если из-за сбоя цепочки вы потеряете свой аккаунт, это большая проблема.
Важный вопрос заключается в том, что оплата меньшей, но все же видимой комиссии за роллап приемлема для приложений и пользователей Ethereum Layer 1 на данный момент, но не для пользователей за пределами мира блокчейна: если вы ранее платили 1 доллар, то более приемлема оплата 0,10 доллара; Но если вы ранее заплатили 0 долларов, то платить 0,10 доллара недопустимо. Это относится как к текущим централизованным приложениям, так и к небольшим проектам уровня 1, которые часто имеют очень низкие комиссии при небольшой пользовательской базе.
Возникает вопрос: какой из этих сложных компромиссов между свертками, валидиумами и другими системами является разумным для конкретного приложения?
Роллапы、Валидиумы、Отключено
Первый аспект безопасности и масштаба, который мы рассмотрим, можно описать следующим образом: если вы владеете активом, который был выпущен на уровне 1, а затем депонирован на уровне 2, а затем переведен на свой счет, можете ли вы быть уверены, что сможете вернуть этот актив на уровень 1? **
В то же время возникает аналогичный вопрос: какие технологические решения приводят к такой уверенности, и какие компромиссы стоят за этим технологическим выбором? **
Мы можем просто описать проблему с помощью таблицы:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
Стоит отметить, что это упрощенная архитектура и есть много промежуточных элементов на выбор. Например:
Между Rollup и Validium: Тип валидиума, который позволяет любому совершать платежи в сети для покрытия комиссий за транзакции, после чего оператор будет вынужден предоставить некоторые данные цепочке или потерять депозит.
Между Plasma и Validium: Система Plasma обеспечивает накопительные гарантии безопасности и доступность данных вне сети (DA), но поддерживает только ограниченное количество приложений. Система может предоставлять полный EVM и гарантии уровня Plasma для пользователей, которые не используют эти более сложные приложения, и гарантии уровня валидиума для пользователей, которые используют эти приложения.
Эти промежуточные варианты можно рассматривать как спектр технологий между накопительными пакетами и валидиумами. Но что мотивирует приложение выбирать конкретную точку в родословной, а не крайнюю левую или крайне правую? Здесь есть два основных фактора:
Стоимость доступности данных на самом Ethereum будет постепенно снижаться по мере совершенствования технологии. Следующий хардфорк Ethereum, Dencun, представил EIP-4844 (также известный как «прото-данкшардинг»), который обеспечивает DA в блокчейне около 32 кБ/сек. Ожидается, что в течение следующих нескольких лет это число будет постепенно увеличиваться по мере полного развертывания danksharding, в конечном итоге достигнув целевого показателя DA около 1,3 МБ/с. В то же время улучшения в сжатии данных позволят нам делать больше с тем же объемом данных.
Потребности самого приложения: Сколько теряет пользователь из-за высоких комиссий по сравнению с проблемами с приложением? ** Финансовые приложения теряют больше из-за сбоев приложений; Игры и социальные сети предполагают большое количество активности на одного пользователя, и ценность активности относительно низкая, поэтому компромисс между безопасностью для них разный.
Этот компромисс выглядит примерно так:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
Еще одна частичная гарантия, о которой стоит упомянуть, — это предварительные подтверждения. Предварительное подтверждение — это сообщение, подписанное некоторыми участниками свертки или валидия, в котором говорится: «Мы доказали, что эти транзакции включены в этот порядок, и что корень после состояния — этот». Эти участники могут подписать предварительное подтверждение, которое не соответствует фактической ситуации в более поздние сроки; Но если они это делают, они сжигают депозит. Это полезно для приложений с низкой стоимостью, таких как потребительские платежи, в то время как приложения с высокой стоимостью, такие как многомиллионные финансовые переводы, могут ожидать «регулярного» подтверждения от полной поддержки безопасности системы.
Предварительную проверку можно рассматривать как еще один пример гибридной системы, аналогичной упомянутой выше «гибридной системе Plasma/Validium», но на этот раз между Rollup (или Validium) с полной безопасностью, но высокой задержкой и системой с более низким уровнем безопасности, но меньшей задержкой. Приложения, которым требуется меньшая задержка, получают более низкий уровень безопасности, но могут сосуществовать в той же экосистеме, что и приложения, которым требуется более высокая задержка в обмен на максимальную безопасность.
Чтение Ethereum без разрешения
Другая, менее продуманная, но все же очень важная форма подключения связана со способностью системы читать блокчейн Ethereum. В частности, это включает в себя возможность отката, когда Ethereum нужно откатить. Чтобы понять, почему это важно, рассмотрим следующий сценарий:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
Предположим, как показано на схеме, в цепочке Ethereum происходит откат. Это может быть временный сбой в рамках эпохи, когда цепочка не была завершена, или может быть так, что сеть была неактивна, и слишком много валидаторов были отключены, и цепочка не была завершена в течение длительного периода времени.
Наихудший сценарий, к которому это может привести, следующий. Допустим, первый блок верхней цепочки считывает какие-то данные из крайнего левого блока цепочки Ethereum. Например, кто-то вносит 100 ETH на Ethereum в верхнюю цепочку. Затем происходит откат с Ethereum. Однако отката верхней цепи не происходит. В результате будущий блок верхней цепочки корректно следовал за новым блоком новой правильной цепочки Ethereum, но теперь результат неправильной старой цепочки (т.е. депозит в размере 100 ETH) все еще существует в верхней цепочке. Эта уязвимость может позволить создать валюту, которая конвертирует ETH в верхней цепочке в частичный резерв.
Решить эту проблему можно двумя способами:
Верхняя цепочка может считывать только те блоки Ethereum, которые были доработаны, поэтому нет необходимости в операции отката. **
Если на Ethereum произойдет откат, верхняя цепочка также может откатиться назад. **
И то, и другое может предотвратить это. Первый проще в реализации, но он может привести к длительной потере функциональности, если Ethereum войдет в период бездействия. Последний сложнее в реализации, но всегда обеспечивает оптимальную функциональность.
Важно отметить, что в первом способе (1) есть особый случай. Если атака 51% создает два несовместимых блока в Ethereum, и оба блока кажутся завершенными одновременно, то верхняя цепочка может выбрать неправильный блок (т. е. блок, который консенсус сообщества Ethereum в конечном итоге не поддерживает) и его необходимо откатить, чтобы переключиться на правильный блок. Возможно, нет необходимости писать код заранее, чтобы справиться с этой ситуацией; Он может справиться с этим, выполнив хардфорк верхней цепочки.
Возможность для блокчейнов считывать данные в Ethereum без разрешений ценна по следующим причинам:
Уменьшите количество проблем с безопасностью, связанных с кроссчейнингом токенов, выпущенных на Ethereum (или другом уровне 2), в этой цепочке.
Позволяет кошелькам абстракции учетной записи, использующим общую структуру хранения ключей для безопасного хранения активов в цепочке.
Первая причина важна, хотя эта важность уже может быть широко признана; И вторая причина не менее важна, так как она означает, что вы можете иметь кошелек, легко менять ключи и хранить активы в разных цепочках.
Делает ли наличие моста цепочку валидной?
Допустим, топ-чейн начинается как одна цепочка, а затем кто-то помещает кроссчейн-контракт на Ethereum. Кроссчейн-контракт — это просто контракт, который принимает заголовок блока верхней цепочки, проверяя, что любой заголовок, отправленный в него, поставляется с действительным сертификатом, указывающим, что он принят консенсусом верхней цепочки, и добавляет этот заголовок в список. На основе этого могут быть созданы приложения для включения таких функций, как депонирование и вывод токенов. После того, как такой мост будет создан, обеспечит ли он какие-либо гарантии безопасности активов, о которых мы упоминали ранее?
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
Пока нет! На это есть две причины:
Мы проверяем, что блок подписан, но мы не проверяем, что переход состояния неправильный. Таким образом, если вы выпускаете активы на Ethereum, которые депонируются в верхней цепочке, а валидаторы верхней цепочки являются мошенниками, они могут подписать недействительный переход состояния и украсть эти активы.
У верхней цепи по-прежнему нет возможности считывать данные Ethereum. В результате вы даже не можете внести нативные активы Ethereum в верхнюю цепочку, не полагаясь на другие (и потенциально небезопасные) сторонние мосты.
Теперь давайте сделаем мост валидацией: он проверяет не только консенсус, но и ZK-SNARK, который доказывает, что состояние любого нового блока вычисляется правильно.
Как только это будет сделано, валидаторы топ-чейна больше не смогут украсть ваши средства. Они могут опубликовать блок, содержащий непригодные для использования данные, не позволяя всем выйти, но они не могут украсть его (если только они не пытаются получить выкуп для пользователей в обмен на утечку данных, которая позволяет им выйти). Это та же модель безопасности, что и валидиумы.
Однако мы до сих пор не решили вторую проблему: топ-чейн не может читать Ethereum.
Для этого нам нужно сделать одну из двух вещей:
Разместите кроссчейн-контракт, который подтверждает окончательный блок Ethereum в верхней цепочке.
Каждый блок в топчейне должен содержать хэш самого последнего блока Ethereum и иметь правило выбора форка, которое обеспечивает хэш-ссылку. То есть, блок топчейна, связанный с блоком Ethereum, который не входит в каноническую цепочку, сам по себе является неканоническим, и если блокчейн топчейна связан с блоком Ethereum, который изначально был каноническим, но позже становится неканоническим, то блок топ-цепочки также должен стать неканоническим.
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
Фиолетовая ссылка на диаграмме может быть как хеш-ссылкой, так и контрактом-мостом, который проверяет консенсус Ethereum.
Достаточно ли этого? Как оказалось, этого оказалось недостаточно, потому что были какие-то небольшие особые случаи:
Что произойдет, если Ethereum будет атакован 51%? **
Как справиться с обновлением хардфорка Ethereum? **
Что делать с хардфорком апгрейда топчейна?**
Атака 51% Ethereum будет иметь те же последствия, что и атака 51% верхней цепочки, но в противоположном направлении. Хардфорк Ethereum может привести к тому, что мост Ethereum в верхней цепочке больше не будет действителен. Самое чистое решение этой проблемы — пообещать, что если Ethereum откатит завершенный блок, верхняя цепочка также откатится назад, а если Ethereum сделает хардфорк, топ-цепочка также сделает хардфорк. Такое обещание, возможно, никогда не придется исполнять: вы можете активировать механизм управления в топчейне, и если он увидит доказательства возможной атаки или хардфорка, и сделать хардфорк в верхней цепочке только в том случае, если механизм управления не сработает.
Единственный жизнеспособный ответ на вопрос (3) заключается в том, что наличие какой-либо формы механизма управления на Ethereum сделает контракт моста на Ethereum осведомленным об обновлении верхней цепи после хардфорка.
Описание: Двустороннего моста валидации почти достаточно, чтобы сделать цепочку валидной. Основная оставшаяся проблема заключается в том, что другая цепочка возьмет на себя социальное обязательство по хардфорку, когда с Ethereum произойдет что-то, что приведет к тому, что мост не будет работать.
Заключение
Есть два ключевых аспекта «подключения к Ethereum»:
Безопасность вывода средств на EthereumБезопасность чтения данных Ethereum
Оба параметра важны и имеют разное значение. В обоих случаях родословная существует:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
Обратите внимание, что каждое измерение измеряется двумя разными способами (значит, на самом деле существует четыре измерения?). ): Безопасность извлечения можно измерить (i) уровнем безопасности и (ii) процентом пользователей или вариантов использования, которые выигрывают от самого высокого уровня безопасности, в то время как безопасность чтения может быть измерена (i) способностью ссылки быстро читать блоки Ethereum, в частности, разницей между блоком, который был завершен, и любым блоком, и (ii) силой социальной приверженности ссылки при работе с крайними случаями, такими как атаки 51% и хардфорки.
Есть много проектов, которые имеют ценность в этом дизайн-пространстве. Для некоторых приложений важна высокая безопасность и тесное подключение. Для других приложений приемлемо более слабое подключение для более высокой масштабируемости. Во многих случаях, возможно, лучше всего начать с некоторых из более мягких методов сегодня и постепенно переходить к более тесным связям в течение следующего десятилетия по мере совершенствования технологий.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Папа Виталинк I переопределяет L2
Автор оригинала | Vitalik.eth
Компиляция | Odaily 0xAyA
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
Особая благодарность Карлу Флоершу за отзыв и обзор
Экосистема Ethereum Layer 2 быстро расширялась в течение последнего года. Экосистема ZK-EVM Rollup, представленная StarkNet, Arbitrum, Optimism и Scroll, добилась больших успехов в улучшении безопасности, а на странице L2beat представлена хорошая сводка о статусе каждого проекта. Кроме того, мы видели, как некоторые команды, создающие сайдчейны, начали создавать роллапы (Polygon), некоторые проекты уровня 1 пытались перейти на валидацию (Celo) и предпринимали новые усилия (Linea, Zeth и т. д.).
В результате проекты уровня 2 становятся все более неоднородными. Я ожидаю, что эта тенденция сохранится по следующим причинам:
Некоторые в настоящее время автономные проекты уровня 1 стремятся приблизиться к экосистеме Ethereum и потенциально стать уровнем 2. ** Эти проекты могут потребовать постепенного перехода. Переход сейчас приведет к снижению удобства использования, потому что технология не готова поместить все на роллап; Но слишком позднее переключение может стоить импульса и слишком поздно, чтобы иметь какой-либо смысл. Некоторые централизованные проекты хотят предоставить пользователям больше гарантий безопасности и изучают возможности на основе блокчейна. Во многих случаях эти проекты могут ранее исследовать «цепочки разрешенных консорциумов». На самом деле, им может понадобиться только «средний уровень» децентрализации. Кроме того, они часто имеют очень высокую пропускную способность, что делает их непригодными даже для свертки, по крайней мере, в краткосрочной перспективе. Нефинансовые приложения, такие как игры или социальные сети, хотят быть децентрализованными, но нуждаются только в «среднем уровне» безопасности. Социальные сети, например, на самом деле по-разному обрабатывают разные части приложения: низкочастотные, но важные действия, такие как регистрация имени пользователя и восстановление учетной записи, должны выполняться на Rollup; Высокочастотные и малоценные действия, такие как публикация и опрос, требуют меньше безопасности. Если ваш пост исчезает из-за сбоя цепочки, это приемлемая цена; Но если из-за сбоя цепочки вы потеряете свой аккаунт, это большая проблема.
Важный вопрос заключается в том, что оплата меньшей, но все же видимой комиссии за роллап приемлема для приложений и пользователей Ethereum Layer 1 на данный момент, но не для пользователей за пределами мира блокчейна: если вы ранее платили 1 доллар, то более приемлема оплата 0,10 доллара; Но если вы ранее заплатили 0 долларов, то платить 0,10 доллара недопустимо. Это относится как к текущим централизованным приложениям, так и к небольшим проектам уровня 1, которые часто имеют очень низкие комиссии при небольшой пользовательской базе.
Возникает вопрос: какой из этих сложных компромиссов между свертками, валидиумами и другими системами является разумным для конкретного приложения?
Роллапы、Валидиумы、Отключено
Первый аспект безопасности и масштаба, который мы рассмотрим, можно описать следующим образом: если вы владеете активом, который был выпущен на уровне 1, а затем депонирован на уровне 2, а затем переведен на свой счет, можете ли вы быть уверены, что сможете вернуть этот актив на уровень 1? **
В то же время возникает аналогичный вопрос: какие технологические решения приводят к такой уверенности, и какие компромиссы стоят за этим технологическим выбором? **
Мы можем просто описать проблему с помощью таблицы:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
Стоит отметить, что это упрощенная архитектура и есть много промежуточных элементов на выбор. Например:
Эти промежуточные варианты можно рассматривать как спектр технологий между накопительными пакетами и валидиумами. Но что мотивирует приложение выбирать конкретную точку в родословной, а не крайнюю левую или крайне правую? Здесь есть два основных фактора:
Стоимость доступности данных на самом Ethereum будет постепенно снижаться по мере совершенствования технологии. Следующий хардфорк Ethereum, Dencun, представил EIP-4844 (также известный как «прото-данкшардинг»), который обеспечивает DA в блокчейне около 32 кБ/сек. Ожидается, что в течение следующих нескольких лет это число будет постепенно увеличиваться по мере полного развертывания danksharding, в конечном итоге достигнув целевого показателя DA около 1,3 МБ/с. В то же время улучшения в сжатии данных позволят нам делать больше с тем же объемом данных. Потребности самого приложения: Сколько теряет пользователь из-за высоких комиссий по сравнению с проблемами с приложением? ** Финансовые приложения теряют больше из-за сбоев приложений; Игры и социальные сети предполагают большое количество активности на одного пользователя, и ценность активности относительно низкая, поэтому компромисс между безопасностью для них разный.
Этот компромисс выглядит примерно так:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
Еще одна частичная гарантия, о которой стоит упомянуть, — это предварительные подтверждения. Предварительное подтверждение — это сообщение, подписанное некоторыми участниками свертки или валидия, в котором говорится: «Мы доказали, что эти транзакции включены в этот порядок, и что корень после состояния — этот». Эти участники могут подписать предварительное подтверждение, которое не соответствует фактической ситуации в более поздние сроки; Но если они это делают, они сжигают депозит. Это полезно для приложений с низкой стоимостью, таких как потребительские платежи, в то время как приложения с высокой стоимостью, такие как многомиллионные финансовые переводы, могут ожидать «регулярного» подтверждения от полной поддержки безопасности системы.
Предварительную проверку можно рассматривать как еще один пример гибридной системы, аналогичной упомянутой выше «гибридной системе Plasma/Validium», но на этот раз между Rollup (или Validium) с полной безопасностью, но высокой задержкой и системой с более низким уровнем безопасности, но меньшей задержкой. Приложения, которым требуется меньшая задержка, получают более низкий уровень безопасности, но могут сосуществовать в той же экосистеме, что и приложения, которым требуется более высокая задержка в обмен на максимальную безопасность.
Чтение Ethereum без разрешения
Другая, менее продуманная, но все же очень важная форма подключения связана со способностью системы читать блокчейн Ethereum. В частности, это включает в себя возможность отката, когда Ethereum нужно откатить. Чтобы понять, почему это важно, рассмотрим следующий сценарий:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
Предположим, как показано на схеме, в цепочке Ethereum происходит откат. Это может быть временный сбой в рамках эпохи, когда цепочка не была завершена, или может быть так, что сеть была неактивна, и слишком много валидаторов были отключены, и цепочка не была завершена в течение длительного периода времени.
Наихудший сценарий, к которому это может привести, следующий. Допустим, первый блок верхней цепочки считывает какие-то данные из крайнего левого блока цепочки Ethereum. Например, кто-то вносит 100 ETH на Ethereum в верхнюю цепочку. Затем происходит откат с Ethereum. Однако отката верхней цепи не происходит. В результате будущий блок верхней цепочки корректно следовал за новым блоком новой правильной цепочки Ethereum, но теперь результат неправильной старой цепочки (т.е. депозит в размере 100 ETH) все еще существует в верхней цепочке. Эта уязвимость может позволить создать валюту, которая конвертирует ETH в верхней цепочке в частичный резерв.
Решить эту проблему можно двумя способами:
Верхняя цепочка может считывать только те блоки Ethereum, которые были доработаны, поэтому нет необходимости в операции отката. ** Если на Ethereum произойдет откат, верхняя цепочка также может откатиться назад. **
И то, и другое может предотвратить это. Первый проще в реализации, но он может привести к длительной потере функциональности, если Ethereum войдет в период бездействия. Последний сложнее в реализации, но всегда обеспечивает оптимальную функциональность.
Важно отметить, что в первом способе (1) есть особый случай. Если атака 51% создает два несовместимых блока в Ethereum, и оба блока кажутся завершенными одновременно, то верхняя цепочка может выбрать неправильный блок (т. е. блок, который консенсус сообщества Ethereum в конечном итоге не поддерживает) и его необходимо откатить, чтобы переключиться на правильный блок. Возможно, нет необходимости писать код заранее, чтобы справиться с этой ситуацией; Он может справиться с этим, выполнив хардфорк верхней цепочки.
Возможность для блокчейнов считывать данные в Ethereum без разрешений ценна по следующим причинам:
Первая причина важна, хотя эта важность уже может быть широко признана; И вторая причина не менее важна, так как она означает, что вы можете иметь кошелек, легко менять ключи и хранить активы в разных цепочках.
Делает ли наличие моста цепочку валидной?
Допустим, топ-чейн начинается как одна цепочка, а затем кто-то помещает кроссчейн-контракт на Ethereum. Кроссчейн-контракт — это просто контракт, который принимает заголовок блока верхней цепочки, проверяя, что любой заголовок, отправленный в него, поставляется с действительным сертификатом, указывающим, что он принят консенсусом верхней цепочки, и добавляет этот заголовок в список. На основе этого могут быть созданы приложения для включения таких функций, как депонирование и вывод токенов. После того, как такой мост будет создан, обеспечит ли он какие-либо гарантии безопасности активов, о которых мы упоминали ранее?
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
Пока нет! На это есть две причины:
Мы проверяем, что блок подписан, но мы не проверяем, что переход состояния неправильный. Таким образом, если вы выпускаете активы на Ethereum, которые депонируются в верхней цепочке, а валидаторы верхней цепочки являются мошенниками, они могут подписать недействительный переход состояния и украсть эти активы.
Теперь давайте сделаем мост валидацией: он проверяет не только консенсус, но и ZK-SNARK, который доказывает, что состояние любого нового блока вычисляется правильно.
Как только это будет сделано, валидаторы топ-чейна больше не смогут украсть ваши средства. Они могут опубликовать блок, содержащий непригодные для использования данные, не позволяя всем выйти, но они не могут украсть его (если только они не пытаются получить выкуп для пользователей в обмен на утечку данных, которая позволяет им выйти). Это та же модель безопасности, что и валидиумы.
Однако мы до сих пор не решили вторую проблему: топ-чейн не может читать Ethereum.
Для этого нам нужно сделать одну из двух вещей:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
Фиолетовая ссылка на диаграмме может быть как хеш-ссылкой, так и контрактом-мостом, который проверяет консенсус Ethereum.
Достаточно ли этого? Как оказалось, этого оказалось недостаточно, потому что были какие-то небольшие особые случаи:
Что произойдет, если Ethereum будет атакован 51%? ** Как справиться с обновлением хардфорка Ethereum? ** Что делать с хардфорком апгрейда топчейна?**
Атака 51% Ethereum будет иметь те же последствия, что и атака 51% верхней цепочки, но в противоположном направлении. Хардфорк Ethereum может привести к тому, что мост Ethereum в верхней цепочке больше не будет действителен. Самое чистое решение этой проблемы — пообещать, что если Ethereum откатит завершенный блок, верхняя цепочка также откатится назад, а если Ethereum сделает хардфорк, топ-цепочка также сделает хардфорк. Такое обещание, возможно, никогда не придется исполнять: вы можете активировать механизм управления в топчейне, и если он увидит доказательства возможной атаки или хардфорка, и сделать хардфорк в верхней цепочке только в том случае, если механизм управления не сработает.
Единственный жизнеспособный ответ на вопрос (3) заключается в том, что наличие какой-либо формы механизма управления на Ethereum сделает контракт моста на Ethereum осведомленным об обновлении верхней цепи после хардфорка.
Описание: Двустороннего моста валидации почти достаточно, чтобы сделать цепочку валидной. Основная оставшаяся проблема заключается в том, что другая цепочка возьмет на себя социальное обязательство по хардфорку, когда с Ethereum произойдет что-то, что приведет к тому, что мост не будет работать.
Заключение
Есть два ключевых аспекта «подключения к Ethereum»:
Безопасность вывода средств на Ethereum Безопасность чтения данных Ethereum
Оба параметра важны и имеют разное значение. В обоих случаях родословная существует:
! [Папа Виталинк I переопределяет L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
Обратите внимание, что каждое измерение измеряется двумя разными способами (значит, на самом деле существует четыре измерения?). ): Безопасность извлечения можно измерить (i) уровнем безопасности и (ii) процентом пользователей или вариантов использования, которые выигрывают от самого высокого уровня безопасности, в то время как безопасность чтения может быть измерена (i) способностью ссылки быстро читать блоки Ethereum, в частности, разницей между блоком, который был завершен, и любым блоком, и (ii) силой социальной приверженности ссылки при работе с крайними случаями, такими как атаки 51% и хардфорки.
Есть много проектов, которые имеют ценность в этом дизайн-пространстве. Для некоторых приложений важна высокая безопасность и тесное подключение. Для других приложений приемлемо более слабое подключение для более высокой масштабируемости. Во многих случаях, возможно, лучше всего начать с некоторых из более мягких методов сегодня и постепенно переходить к более тесным связям в течение следующего десятилетия по мере совершенствования технологий.