За последний год экосистема быстро расширилась. Экосистема роллапа ZK-EVM, традиционно представленная StarkNet, Arbitrum, Optimism и Scroll, быстро прогрессирует, повышая свою безопасность, а на странице L2beat представлена хорошая сводка о статусе каждого проекта.
Кроме того, мы видим, как команды создают сайдчейны и роллапы (например, Polygon), некоторые L1-проекты, пытающиеся перейти к валидации (например, Celo), и совершенно новые попытки (например, Linea, Zeth...). ）。
Одним из неизбежных следствий этого является то, что мы видим, что L2-проекты имеют тенденцию быть более гетерогенными (т.е. «изомеризованными»). В криптовалюте «гетерогенность» относится к сосуществованию или смешению различных видов вещей или разной природы. Этот термин часто используется для описания различных блокчейнов, протоколов, технологий или активов, которые имеют разные характеристики, правила или атрибуты. Я ожидаю, что эта тенденция сохранится по следующим причинам:
В настоящее время ряд независимых проектов L1 стремятся более тесно взаимодействовать с экосистемой Ethereum и потенциально трансформироваться в проекты L2. В этих проектах может потребоваться поэтапный подход к переходу. Немедленный общий переход снизит удобство использования, потому что технология не готова поместить все в сценарий свертки. И в более позднем переходном периоде может быть слишком поздно жертвовать импульсом и иметь практический смысл.
Некоторые централизованные проекты хотят обеспечить большую безопасность для своих пользователей и изучают возможности на основе блокчейна. Во многих случаях эти проекты, возможно, рассматривали «блокчейны консорциумов с ограниченным доступом» в прошлом. На самом деле, им может потребоваться только выйти на уровень «полуцентрализации». Кроме того, они, как правило, имеют очень высокую пропускную способность, что делает их непригодными для схем свертки, по крайней мере, в краткосрочной перспективе.
Нефинансовые приложения, такие как игры или социальные сети, хотят быть децентрализованными, но нуждаются только в определенном уровне безопасности.
В случае с социальными сетями на самом деле есть разные части приложения, к которым подходят по-разному: редкие и ценные действия, такие как регистрация имени пользователя и восстановление учетной записи, должны выполняться в накопительной схеме, но частые и малоценные действия, такие как сообщения и опросы, требуют меньшей безопасности, что является приемлемой ценой, которую можно заплатить, если блокчейн выйдет из строя и приведет к исчезновению ваших сообщений; Но если сбой блокчейна приводит к тому, что вы теряете свою учетную запись, это более серьезная проблема.
Важной темой является то, что в то время как приложения и пользователи, которые в настоящее время находятся на Ethereum L1, готовы платить меньшие, но все же заметные сборы за роллап в краткосрочной перспективе, пользователи из мира, не связанного с блокчейном, менее склонны делать это: если вы ранее платили 1 доллар, то более приемлемо платить 0,10 доллара, а если вы ранее платили 0 долларов, это трудно принять.
Это относится как к приложениям, которые до сих пор централизованы, так и к небольшим L1-проектам, которые часто имеют чрезвычайно низкие комиссии, когда их пользовательская база невелика.
Возникает закономерный вопрос: какой из этих сложных компромиссов между накопительными схемами, валидиумами и другими системами является разумным для конкретного приложения?
Роллапы, валидиумы и отключенные
Первый аспект безопасности и масштабируемости, который мы рассмотрим, можно описать следующим образом: если вы владеете активом, выпущенным на L1, затем депонируете его на L2, а затем передаете вам, насколько вы уверены, что сможете вернуть актив в L1?
С этим связан и вопрос: какой выбор технологии приводит к такому уровню уверенности, и каковы компромиссы этого технологического выбора?
Мы можем проиллюстрировать проблему простой диаграммой:
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)
Стоит отметить, что это упрощенный сценарий, в котором существует множество промежуточных вариантов. Например:
Между роллапом и валидиумом: В валидиуме любой желающий может совершить ончейн-платеж для покрытия комиссии за транзакцию, после чего оператор будет вынужден предоставить некоторые данные цепочке или потерять депозит.
Между плазмой и валидиумом: плазменная система обеспечивает накопительные гарантии безопасности с доступностью данных вне сети, но поддерживает только ограниченное количество приложений. Система может предоставить полный EVM с гарантиями уровня плазмы для тех, кто не использует эти более сложные приложения, а также гарантиями уровня валидности для тех, кто использует эти приложения.
Эти промежуточные варианты можно рассматривать как спектр между сверткой и валидиумом. Но что побуждает приложение выбирать конкретную точку в этом спектре, а не точку слева или справа? Здесь есть два основных фактора:
**1. Стоимость доступности нативных данных Ethereum, которая будет снижаться со временем по мере развития технологии. Следующий хардфорк Ethereum, Dencun, представляет EIP-4844 (также известный как «прото-данкшардинг»), который обеспечивает доступность данных в сети примерно 32 кБ/с.
Ожидается, что эта доступность данных будет постепенно увеличиваться в течение следующих нескольких лет с полным развертыванием danksharding, с конечной целью — около 1,3 МБ/с. В то же время улучшения в сжатии данных позволят нам делать больше с тем же объемом данных.
**2. Собственные потребности приложения: Насколько серьезны потери пользователя с точки зрения высоких затрат относительно проблемы с приложением? ** Финансовые приложения потеряют больше из-за сбоя приложения; Игры и социальные сети связаны с большой активностью пользователей и относительно малоценными действиями, поэтому для них имеют смысл идти на различные компромиссы в области безопасности.
Этот компромисс выглядит примерно так:
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)
Еще один тип, о котором стоит упомянуть, — это предварительные подтверждения. Предварительное подтверждение — это сообщение, подписанное группой участников свертки или валидия, в котором говорится: «Мы доказываем, что эти транзакции включены в этот порядок, и что корень после состояния — этот». Эти участники могут подписать предварительное подтверждение, которое не соответствует действительности, но если это так, то их вклады будут уничтожены.
Это полезно для приложений с низкой стоимостью, таких как потребительские платежи, в то время как приложения с высокой стоимостью, такие как многомиллионные финансовые переводы, могут ожидать «регулярного» подтверждения, подкрепленного целостностью безопасности системы.
Предварительное подтверждение можно рассматривать как еще один пример гибридной системы, похожей на упомянутый выше «гибрид плазмы и валидия», но на этот раз между накопительным пакетом (или валидиумом) с полной безопасностью, но высокой задержкой и системой с более низким уровнем безопасности, но низкой задержкой. Приложения, требующие меньшей задержки, получат более низкий уровень безопасности, но могут сосуществовать в той же экосистеме, что и те, которые готовы терпеть более высокую задержку для максимальной безопасности.
Чтение Ethereum без доверия
Другая форма связи, которая менее рассматривается, но все же очень важна, связана со способностью системы читать блокчейн Ethereum. В частности, это включает в себя способность системы откатываться при возникновении Ethereum. Чтобы понять, почему это важно, рассмотрим следующий сценарий:
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)
Допустим, что в блокчейне Ethereum происходит откат, как показано на диаграмме. Это может быть временный сбой в рамках эпохи, когда блокчейн еще не завершен; Или это может быть связано с тем, что слишком много валидаторов находятся в автономном режиме, что приводит к неактивным периодам утечки, которые блокчейн не может завершить в течение более длительного периода времени.
Наихудший сценарий, который может возникнуть в результате этого, выглядит следующим образом: предположим, что первый блок верхней цепочки считывает некоторые данные из крайнего левого блока цепочки Ethereum. Например, кто-то вносит 100 ETH на Ethereum в верхнюю цепочку. Затем Ethereum откатился назад, но топовая цепочка этого не сделала. В результате будущие блоки в верхней цепочке правильно следуют за новыми, правильными блоками в блокчейне Ethereum, но неправильная транзакция (т.е. депозит в размере 100 ETH) все еще существует в верхней цепочке. Эта уязвимость может привести к дополнительной эмиссии монет, превращая ETH в верхней цепочке в частичные резервы.
Решить эту проблему можно двумя способами:
Верхняя цепочка может читать только те блоки, которые были доработаны Ethereum, поэтому ее никогда не нужно откатывать;
Если откат происходит на Ethereum, откат может произойти и на верхней цепочке. И то, и другое может предотвратить эту проблему. Первый проще в реализации, но если Ethereum войдет в период неактивной утечки, это может привести к потере функциональности в течение длительного периода времени. Последний сложнее в реализации, но гарантирует, что он всегда будет иметь лучшие функции.
Обратите внимание, что для первого метода действительно существует особый случай. Если произойдет атака 51% на Ethereum, в результате которой одновременно появятся два новых несовместимых блока, оба из которых, по-видимому, были завершены, то верхняя цепочка может выбрать неправильный блок (т. е. блок, который социальный консенсус Ethereum в конечном итоге не поддерживает) и ему придется откатиться, чтобы переключиться на правильный блок. Возможно, нет необходимости заранее писать код, чтобы справиться с этой ситуацией; С этим можно справиться, выполнив хардфорк верхней цепочки.
Есть две важные причины, по которым блокчейн может читать Ethereum без доверия:
Во-первых, эта возможность может уменьшить проблемы безопасности, связанные с подключением токенов, выпущенных на Ethereum (или других решениях уровня 2), к этой цепочке;
Во-вторых, эта возможность позволяет кошелькам с абстракцией учетных записей, которые используют общую структуру хранения ключей для безопасного хранения активов в цепочке.
Несмотря на разногласия, важность первого подхода широко признается. Опять же, второй способ важен, потому что он означает, что у вас может быть кошелек, который может легко менять ключи и хранить активы во многих различных цепочках.
Является ли наличие моста валидиумом?
Допустим, топ-чейн изначально был запущен как самостоятельная цепочка, а потом кто-то развернул контракт моста на Ethereum. Контракт-мост — это просто контракт, который принимает заголовки блоков из верхней цепочки, проверяя, что все заголовки блоков, отправленные в него, сопровождаются действительным сертификатом, который доказывает, что заголовок блока был принят консенсусом верхней цепочки, и добавляет заголовок блока в список.
Приложение может создавать функции поверх этого, такие как ввод и вывод токенов. После того, как такой мост будет создан, обеспечит ли он какие-либо гарантии безопасности активов, о которых мы упоминали ранее?
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)
Пока нет! На это есть две причины:
Мы проверяем подпись блока, но не проверяем правильность перехода состояния. Таким образом, если вы внесете активы, выпущенные на Ethereum, в верхнюю цепочку, и валидатор верхней цепочки станет нечестным, он может подписать недействительный переход состояния, тем самым украв эти активы;
В верхней цепочке по-прежнему нечитаем Ethereum. В результате вы не можете внести собственные активы Ethereum в верхнюю цепочку, если только вы не полагаетесь на другие (и потенциально небезопасные) сторонние мосты.
Теперь давайте построим мост как мост валидатора: он не только проверяет консенсус, но и проверяет, что состояние любого нового блока, вычисленного с помощью доказательств ZK-SNARK, является правильным.
Как только этот шаг будет завершен, валидаторы в верхней цепочке не смогут украсть ваши средства. Они могут опубликовать блок, содержащий непригодные для использования данные, не позволяя всем желающим вывести средства, но они не могут украсть средства (если только они не попытаются раскрыть данные, которые позволяют пользователям вывести свои средства, требуя выкуп). Он имеет ту же модель безопасности, что и валидиумы.
Однако мы до сих пор не решили вторую проблему: топ-чейн не может читать данные Ethereum. Для того, чтобы этого добиться, нам нужно сделать одну из двух вещей:
Поместите бридж-контракт в верхнюю цепочку, которая подтверждает окончательный блок Ethereum;
Включите хэш самого последнего блока Ethereum в каждый блок верхней цепочки и используйте правила выбора форка для обеспечения хэш-ссылки. То есть, сам блок топчейна, который будет связан с блоком Ethereum в неосновной цепочке, не является мейнчейном. Если блок Ethereum, подключенный к блокчейну топчейна, изначально находится в основной цепочке, но позже становится немейнчейном, блок топчейна также должен стать немейнчейном.
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)
Эти фиолетовые ссылки могут быть хеш-ссылками или контрактами-мостами, которые подтверждают консенсус Ethereum
Достаточно ли этого? На самом деле, этого недостаточно, потому что есть несколько небольших крайних случаев:
Что произойдет, если Ethereum подвергнется атаке 51%?
Что делать с обновлением хардфорка Ethereum?
Как справиться с обновлением вашей цепочки после хардфорка?
Атака 51% на Ethereum будет иметь те же последствия, что и атака 51% на верхнюю цепочку, но будет верно обратное. Хардфорк Ethereum может сделать недействительным мост Ethereum в верхней цепочке. Социальное обязательство, т.е. если Ethereum восстановит завершенный блок, он будет восстановлен, а если Ethereum сделает хардфорк, то он будет хардфорк, является самым чистым способом решения этой проблемы.
Такое обещание, возможно, никогда не придется исполнять: если орган управления верхней цепочкой обнаружит доказательства возможной атаки или хардфорка, он может активировать орган управления и только в случае неудачи органа управления в верхней цепочке.
Что касается третьего вопроса, то единственным жизнеспособным ответом является наличие какой-либо формы управления в Ethereum, которая позволила бы контракту-мосту на Ethereum узнать об обновлении верхней цепи после хардфорка.
Описание: Двустороннего моста верификации почти достаточно, чтобы сделать блокчейн валидиумом. Основным оставшимся элементом является социальное обязательство о том, что если с Ethereum произойдет что-то необычное, из-за чего контракт моста не будет работать должным образом, другой блокчейн в ответ сделает хардфорк.
Заключение
«Подключение к Ethereum» имеет два ключевых аспекта:
Безопасность вывода средств на Ethereum;
Ознакомьтесь с безопасностью Ethereum.
И то, и другое очень важно и имеет разные соображения. В обоих случаях существует континуум:
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)
Обратите внимание, что каждое измерение измеряется двумя различными способами (на самом деле их четыре): извлеченная безопасность может быть измерена по (i) уровню безопасности и (ii) тому, сколько пользователей или пользователей получают выгоду от самого высокого уровня безопасности;
Безопасность чтения можно измерить по (i) тому, насколько быстро канал может считывать блоки Ethereum, и, в частности, чем окончательный блок отличается от любого другого блока, и (ii) насколько зафиксирован канал при работе с крайними случаями, такими как атаки 51% и хардфорки.
Проект имеет ценность во многих областях этого дизайнерского пространства. Для некоторых приложений важен высокий уровень безопасности и тесное подключение. Для других приложений приемлемы более мягкие условия для большей масштабируемости. Во многих случаях, начиная с более свободных условий сегодня, постепенный переход к более тесной связи в течение следующего десятилетия может быть оптимальным по мере совершенствования технологии.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Виталик: Пора прекращать препирательства, мне есть что сказать по поводу определения Layer 2
Оригинальное название: "Различные типы слоев 2"
Текст: Виталик Бутерин
Компиляция: BlockBeats
За последний год экосистема быстро расширилась. Экосистема роллапа ZK-EVM, традиционно представленная StarkNet, Arbitrum, Optimism и Scroll, быстро прогрессирует, повышая свою безопасность, а на странице L2beat представлена хорошая сводка о статусе каждого проекта.
Кроме того, мы видим, как команды создают сайдчейны и роллапы (например, Polygon), некоторые L1-проекты, пытающиеся перейти к валидации (например, Celo), и совершенно новые попытки (например, Linea, Zeth...). ）。
Одним из неизбежных следствий этого является то, что мы видим, что L2-проекты имеют тенденцию быть более гетерогенными (т.е. «изомеризованными»). В криптовалюте «гетерогенность» относится к сосуществованию или смешению различных видов вещей или разной природы. Этот термин часто используется для описания различных блокчейнов, протоколов, технологий или активов, которые имеют разные характеристики, правила или атрибуты. Я ожидаю, что эта тенденция сохранится по следующим причинам:
В настоящее время ряд независимых проектов L1 стремятся более тесно взаимодействовать с экосистемой Ethereum и потенциально трансформироваться в проекты L2. В этих проектах может потребоваться поэтапный подход к переходу. Немедленный общий переход снизит удобство использования, потому что технология не готова поместить все в сценарий свертки. И в более позднем переходном периоде может быть слишком поздно жертвовать импульсом и иметь практический смысл.
Некоторые централизованные проекты хотят обеспечить большую безопасность для своих пользователей и изучают возможности на основе блокчейна. Во многих случаях эти проекты, возможно, рассматривали «блокчейны консорциумов с ограниченным доступом» в прошлом. На самом деле, им может потребоваться только выйти на уровень «полуцентрализации». Кроме того, они, как правило, имеют очень высокую пропускную способность, что делает их непригодными для схем свертки, по крайней мере, в краткосрочной перспективе.
Нефинансовые приложения, такие как игры или социальные сети, хотят быть децентрализованными, но нуждаются только в определенном уровне безопасности.
В случае с социальными сетями на самом деле есть разные части приложения, к которым подходят по-разному: редкие и ценные действия, такие как регистрация имени пользователя и восстановление учетной записи, должны выполняться в накопительной схеме, но частые и малоценные действия, такие как сообщения и опросы, требуют меньшей безопасности, что является приемлемой ценой, которую можно заплатить, если блокчейн выйдет из строя и приведет к исчезновению ваших сообщений; Но если сбой блокчейна приводит к тому, что вы теряете свою учетную запись, это более серьезная проблема.
Важной темой является то, что в то время как приложения и пользователи, которые в настоящее время находятся на Ethereum L1, готовы платить меньшие, но все же заметные сборы за роллап в краткосрочной перспективе, пользователи из мира, не связанного с блокчейном, менее склонны делать это: если вы ранее платили 1 доллар, то более приемлемо платить 0,10 доллара, а если вы ранее платили 0 долларов, это трудно принять.
Это относится как к приложениям, которые до сих пор централизованы, так и к небольшим L1-проектам, которые часто имеют чрезвычайно низкие комиссии, когда их пользовательская база невелика.
Возникает закономерный вопрос: какой из этих сложных компромиссов между накопительными схемами, валидиумами и другими системами является разумным для конкретного приложения?
Роллапы, валидиумы и отключенные
Первый аспект безопасности и масштабируемости, который мы рассмотрим, можно описать следующим образом: если вы владеете активом, выпущенным на L1, затем депонируете его на L2, а затем передаете вам, насколько вы уверены, что сможете вернуть актив в L1?
С этим связан и вопрос: какой выбор технологии приводит к такому уровню уверенности, и каковы компромиссы этого технологического выбора?
Мы можем проиллюстрировать проблему простой диаграммой:
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/641c1134cde471478d058f6d0e2eaab1.jpg)
Стоит отметить, что это упрощенный сценарий, в котором существует множество промежуточных вариантов. Например:
Между роллапом и валидиумом: В валидиуме любой желающий может совершить ончейн-платеж для покрытия комиссии за транзакцию, после чего оператор будет вынужден предоставить некоторые данные цепочке или потерять депозит.
Между плазмой и валидиумом: плазменная система обеспечивает накопительные гарантии безопасности с доступностью данных вне сети, но поддерживает только ограниченное количество приложений. Система может предоставить полный EVM с гарантиями уровня плазмы для тех, кто не использует эти более сложные приложения, а также гарантиями уровня валидности для тех, кто использует эти приложения.
Эти промежуточные варианты можно рассматривать как спектр между сверткой и валидиумом. Но что побуждает приложение выбирать конкретную точку в этом спектре, а не точку слева или справа? Здесь есть два основных фактора:
**1. Стоимость доступности нативных данных Ethereum, которая будет снижаться со временем по мере развития технологии. Следующий хардфорк Ethereum, Dencun, представляет EIP-4844 (также известный как «прото-данкшардинг»), который обеспечивает доступность данных в сети примерно 32 кБ/с.
Ожидается, что эта доступность данных будет постепенно увеличиваться в течение следующих нескольких лет с полным развертыванием danksharding, с конечной целью — около 1,3 МБ/с. В то же время улучшения в сжатии данных позволят нам делать больше с тем же объемом данных.
**2. Собственные потребности приложения: Насколько серьезны потери пользователя с точки зрения высоких затрат относительно проблемы с приложением? ** Финансовые приложения потеряют больше из-за сбоя приложения; Игры и социальные сети связаны с большой активностью пользователей и относительно малоценными действиями, поэтому для них имеют смысл идти на различные компромиссы в области безопасности.
Этот компромисс выглядит примерно так:
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/eb26cf8cf9fde9560ac2bdae8828a175.jpg)
Еще один тип, о котором стоит упомянуть, — это предварительные подтверждения. Предварительное подтверждение — это сообщение, подписанное группой участников свертки или валидия, в котором говорится: «Мы доказываем, что эти транзакции включены в этот порядок, и что корень после состояния — этот». Эти участники могут подписать предварительное подтверждение, которое не соответствует действительности, но если это так, то их вклады будут уничтожены.
Это полезно для приложений с низкой стоимостью, таких как потребительские платежи, в то время как приложения с высокой стоимостью, такие как многомиллионные финансовые переводы, могут ожидать «регулярного» подтверждения, подкрепленного целостностью безопасности системы.
Предварительное подтверждение можно рассматривать как еще один пример гибридной системы, похожей на упомянутый выше «гибрид плазмы и валидия», но на этот раз между накопительным пакетом (или валидиумом) с полной безопасностью, но высокой задержкой и системой с более низким уровнем безопасности, но низкой задержкой. Приложения, требующие меньшей задержки, получат более низкий уровень безопасности, но могут сосуществовать в той же экосистеме, что и те, которые готовы терпеть более высокую задержку для максимальной безопасности.
Чтение Ethereum без доверия
Другая форма связи, которая менее рассматривается, но все же очень важна, связана со способностью системы читать блокчейн Ethereum. В частности, это включает в себя способность системы откатываться при возникновении Ethereum. Чтобы понять, почему это важно, рассмотрим следующий сценарий:
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/4de6c8f1f9b77155639e6a286f4162a1.jpg)
Допустим, что в блокчейне Ethereum происходит откат, как показано на диаграмме. Это может быть временный сбой в рамках эпохи, когда блокчейн еще не завершен; Или это может быть связано с тем, что слишком много валидаторов находятся в автономном режиме, что приводит к неактивным периодам утечки, которые блокчейн не может завершить в течение более длительного периода времени.
Наихудший сценарий, который может возникнуть в результате этого, выглядит следующим образом: предположим, что первый блок верхней цепочки считывает некоторые данные из крайнего левого блока цепочки Ethereum. Например, кто-то вносит 100 ETH на Ethereum в верхнюю цепочку. Затем Ethereum откатился назад, но топовая цепочка этого не сделала. В результате будущие блоки в верхней цепочке правильно следуют за новыми, правильными блоками в блокчейне Ethereum, но неправильная транзакция (т.е. депозит в размере 100 ETH) все еще существует в верхней цепочке. Эта уязвимость может привести к дополнительной эмиссии монет, превращая ETH в верхней цепочке в частичные резервы.
Решить эту проблему можно двумя способами:
Верхняя цепочка может читать только те блоки, которые были доработаны Ethereum, поэтому ее никогда не нужно откатывать;
Если откат происходит на Ethereum, откат может произойти и на верхней цепочке. И то, и другое может предотвратить эту проблему. Первый проще в реализации, но если Ethereum войдет в период неактивной утечки, это может привести к потере функциональности в течение длительного периода времени. Последний сложнее в реализации, но гарантирует, что он всегда будет иметь лучшие функции.
Обратите внимание, что для первого метода действительно существует особый случай. Если произойдет атака 51% на Ethereum, в результате которой одновременно появятся два новых несовместимых блока, оба из которых, по-видимому, были завершены, то верхняя цепочка может выбрать неправильный блок (т. е. блок, который социальный консенсус Ethereum в конечном итоге не поддерживает) и ему придется откатиться, чтобы переключиться на правильный блок. Возможно, нет необходимости заранее писать код, чтобы справиться с этой ситуацией; С этим можно справиться, выполнив хардфорк верхней цепочки.
Есть две важные причины, по которым блокчейн может читать Ethereum без доверия:
Во-первых, эта возможность может уменьшить проблемы безопасности, связанные с подключением токенов, выпущенных на Ethereum (или других решениях уровня 2), к этой цепочке;
Во-вторых, эта возможность позволяет кошелькам с абстракцией учетных записей, которые используют общую структуру хранения ключей для безопасного хранения активов в цепочке.
Несмотря на разногласия, важность первого подхода широко признается. Опять же, второй способ важен, потому что он означает, что у вас может быть кошелек, который может легко менять ключи и хранить активы во многих различных цепочках.
Является ли наличие моста валидиумом?
Допустим, топ-чейн изначально был запущен как самостоятельная цепочка, а потом кто-то развернул контракт моста на Ethereum. Контракт-мост — это просто контракт, который принимает заголовки блоков из верхней цепочки, проверяя, что все заголовки блоков, отправленные в него, сопровождаются действительным сертификатом, который доказывает, что заголовок блока был принят консенсусом верхней цепочки, и добавляет заголовок блока в список.
Приложение может создавать функции поверх этого, такие как ввод и вывод токенов. После того, как такой мост будет создан, обеспечит ли он какие-либо гарантии безопасности активов, о которых мы упоминали ранее?
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/f2e4d6973f59d0520636a41407c9a20a.jpg)
Пока нет! На это есть две причины:
Мы проверяем подпись блока, но не проверяем правильность перехода состояния. Таким образом, если вы внесете активы, выпущенные на Ethereum, в верхнюю цепочку, и валидатор верхней цепочки станет нечестным, он может подписать недействительный переход состояния, тем самым украв эти активы;
В верхней цепочке по-прежнему нечитаем Ethereum. В результате вы не можете внести собственные активы Ethereum в верхнюю цепочку, если только вы не полагаетесь на другие (и потенциально небезопасные) сторонние мосты.
Теперь давайте построим мост как мост валидатора: он не только проверяет консенсус, но и проверяет, что состояние любого нового блока, вычисленного с помощью доказательств ZK-SNARK, является правильным.
Как только этот шаг будет завершен, валидаторы в верхней цепочке не смогут украсть ваши средства. Они могут опубликовать блок, содержащий непригодные для использования данные, не позволяя всем желающим вывести средства, но они не могут украсть средства (если только они не попытаются раскрыть данные, которые позволяют пользователям вывести свои средства, требуя выкуп). Он имеет ту же модель безопасности, что и валидиумы.
Однако мы до сих пор не решили вторую проблему: топ-чейн не может читать данные Ethereum. Для того, чтобы этого добиться, нам нужно сделать одну из двух вещей:
Поместите бридж-контракт в верхнюю цепочку, которая подтверждает окончательный блок Ethereum;
Включите хэш самого последнего блока Ethereum в каждый блок верхней цепочки и используйте правила выбора форка для обеспечения хэш-ссылки. То есть, сам блок топчейна, который будет связан с блоком Ethereum в неосновной цепочке, не является мейнчейном. Если блок Ethereum, подключенный к блокчейну топчейна, изначально находится в основной цепочке, но позже становится немейнчейном, блок топчейна также должен стать немейнчейном.
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/5fa31bfce1306e3527691085ad238a99.jpg)
Эти фиолетовые ссылки могут быть хеш-ссылками или контрактами-мостами, которые подтверждают консенсус Ethereum
Достаточно ли этого? На самом деле, этого недостаточно, потому что есть несколько небольших крайних случаев:
Что произойдет, если Ethereum подвергнется атаке 51%?
Что делать с обновлением хардфорка Ethereum?
Как справиться с обновлением вашей цепочки после хардфорка?
Атака 51% на Ethereum будет иметь те же последствия, что и атака 51% на верхнюю цепочку, но будет верно обратное. Хардфорк Ethereum может сделать недействительным мост Ethereum в верхней цепочке. Социальное обязательство, т.е. если Ethereum восстановит завершенный блок, он будет восстановлен, а если Ethereum сделает хардфорк, то он будет хардфорк, является самым чистым способом решения этой проблемы.
Такое обещание, возможно, никогда не придется исполнять: если орган управления верхней цепочкой обнаружит доказательства возможной атаки или хардфорка, он может активировать орган управления и только в случае неудачи органа управления в верхней цепочке.
Что касается третьего вопроса, то единственным жизнеспособным ответом является наличие какой-либо формы управления в Ethereum, которая позволила бы контракту-мосту на Ethereum узнать об обновлении верхней цепи после хардфорка.
Описание: Двустороннего моста верификации почти достаточно, чтобы сделать блокчейн валидиумом. Основным оставшимся элементом является социальное обязательство о том, что если с Ethereum произойдет что-то необычное, из-за чего контракт моста не будет работать должным образом, другой блокчейн в ответ сделает хардфорк.
Заключение
«Подключение к Ethereum» имеет два ключевых аспекта:
Безопасность вывода средств на Ethereum;
Ознакомьтесь с безопасностью Ethereum.
И то, и другое очень важно и имеет разные соображения. В обоих случаях существует континуум:
! [Виталик: Пора прекратить препирательства, мне есть что сказать по поводу определения Слоя 2] (https://cdn-img.panewslab.com//panews/2022/10/31/images/8c582e1b1fa730531869238da7787bbc.jpg)
Обратите внимание, что каждое измерение измеряется двумя различными способами (на самом деле их четыре): извлеченная безопасность может быть измерена по (i) уровню безопасности и (ii) тому, сколько пользователей или пользователей получают выгоду от самого высокого уровня безопасности;
Безопасность чтения можно измерить по (i) тому, насколько быстро канал может считывать блоки Ethereum, и, в частности, чем окончательный блок отличается от любого другого блока, и (ii) насколько зафиксирован канал при работе с крайними случаями, такими как атаки 51% и хардфорки.
Проект имеет ценность во многих областях этого дизайнерского пространства. Для некоторых приложений важен высокий уровень безопасности и тесное подключение. Для других приложений приемлемы более мягкие условия для большей масштабируемости. Во многих случаях, начиная с более свободных условий сегодня, постепенный переход к более тесной связи в течение следующего десятилетия может быть оптимальным по мере совершенствования технологии.