Версия тестовой сети Dencun для обновления сети Ethereum была запущена на тестовой сети Goerli 17 января 2024 г., а тестовая сеть Sepolia была успешно запущена 30 января. Обновление Dencun становится все ближе и ближе.

После обновления тестовой сети Holesky 7 февраля наступит обновление основной сети. Запуск обновления в сети Cancun официально назначен на 13 марта 2024 года.

Почти каждое обновление Ethereum сопровождается значительными тенденциями на рынке. Если вспомнить последнее обновление 12 апреля 2023 года, известное как Шанхайское обновление, то проекты, связанные с Proof-of-Stake (PoS), пользовались повышенным спросом на рынке.

Если мы будем следовать предыдущему опыту, то перед предстоящим обновлением Dencun, вероятно, появятся возможности для стратегического позиционирования.

Однако из-за технической сложности, связанной с обновлением Dencun, его нельзя описать так же кратко, как обновление в Шанхае, одной фразой вроде "Ethereum переходит от PoW к PoS". Такая сложность затрудняет определение ключевых моментов для стратегического позиционирования.

Поэтому цель этой статьи - объяснить технические детали модернизации Dencun простым и понятным языком. Она проведет читателей через все тонкости этой модернизации, подчеркнет ее связь с доступностью данных (DA), решениями уровня 2 и другими важными аспектами.

01. EIP 4484

EIP-4844 является наиболее важным предложением в обновлении Dencun и знаменует собой значительный шаг для Ethereum на пути децентрализованного масштабирования.

Говоря простым языком, текущие решения Ethereum Layer 2 требуют отправки транзакций, происходящих на втором уровне, в calldata главной сети Ethereum. Эти данные используются узлами для проверки достоверности блоков в сети уровня 2.

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

EIP-4844 представляет экономичное решение, создавая новый тип области хранения, называемый Binary Large Object (BLOB). Он вводит новый тип транзакций, известный как "BLOB-Carrying Transaction", чтобы заменить данные транзакций, которые до обновления хранились в calldata. Этот инновационный подход помогает экосистеме Ethereum Layer 2 добиваться экономии газа.

Почему хранение BLOB является экономически эффективным？

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

Вместо этого, EL может получить доступ только к ссылкам на данные BLOB, а реальные данные BLOB могут быть загружены и сохранены только Ethereum Consensus Layer (CL, также известные как узлы-маяки). Требования к памяти и вычислительным ресурсам для хранения BLOB-данных значительно ниже, чем для хранения обычных данных Ethereum calldata.

Кроме того, BLOB имеет отличительную особенность - он может храниться только в течение ограниченного периода времени (обычно около 18 дней) и не может бесконечно расширяться, как размер бухгалтерской книги Ethereum.

Срок действия BLOB-хранилища

В отличие от постоянной бухгалтерской книги блокчейна, BLOBы - это временное хранилище, которое доступно в течение 4 096 эпох, или примерно 18 дней.

После истечения срока действия большинство клиентов consensus не смогут получить определенные данные из BLOB. Однако доказательство его предыдущего существования останется в мейннете в виде обязательств KZG и будет постоянно храниться в мейннете Ethereum.

Почему 18 дней? Это компромисс между стоимостью и эффективностью хранения.

Прежде всего, мы должны рассмотреть наиболее интуитивно понятных бенефициаров этого обновления, оптимистичные роллапы (такие как Arbitrum и Optimism), потому что в оптимистичных роллапах есть 7-дневное временное окно Fraud Proof. Данные о транзакциях, хранящиеся в блобе, - это именно то, что нужно Optimistic Rollups при запуске задачи.

Поэтому срок действия блоба должен гарантировать, что оптимистичные роллы Fraud Proof будут доступны. Для простоты сообщество Ethereum выбрало значение 2 в степени 12 (4 096 эпох получаются из 2^12, а одна эпоха равна примерно 6,4 минутам).

Транзакция с BLOB-носителями и BLOB

Понимание взаимосвязи между этими двумя понятиями важно для понимания роли BLOBs в доступности данных (DA).

Первый вариант является общим предложением EIP-4484 и представляет собой новый тип транзакций, а второй можно понимать как место временного хранения для транзакций второго уровня.

Взаимосвязь между ними можно понять так: большая часть данных первого уровня (данные транзакций уровня 2) хранится во втором. Оставшиеся данные, т.е. обязательства по BLOB-данным, будут храниться в calldata основной сети. Другими словами, обещания могут быть прочитаны EVM.

Задание можно представить себе как построение всех транзакций в BLOB в дерево Меркла, а затем только корень Меркла, который и является заданием, может быть доступен контракту.

Этого можно добиться хитро: хотя EVM не может знать конкретное содержимое BLOB, контракт EVM может проверить подлинность данных транзакции, зная Commitment.

02. Взаимосвязь между BLOB и уровнем 2

Технология Rollup обеспечивает доступность данных (DA), загружая данные в главную сеть Ethereum, но она не предназначена для того, чтобы смарт-контракты L1 напрямую считывали или проверяли эти загруженные данные.

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

До обновления Dencun, как уже говорилось выше, Optimistic Rollups будет публиковать данные о транзакциях в Ethereum в виде calldata. Поэтому любой может использовать эту информацию о транзакциях, чтобы воспроизвести состояние и проверить правильность работы сети уровня 2.

Нетрудно понять, что данные о транзакциях в рулонах должны быть дешевыми, открытыми и прозрачными. Calldata - не лучшее место для хранения данных транзакций специально для Layer 2, а BLOB-Carrying Transaction создан специально для Rollup.

На этом этапе Вы можете задаться вопросом о значении данных о транзакциях.

В действительности данные о транзакциях используются только в определенных сценариях:

• Для Optimistic Rollup, основанного на предположении о доверии, существует вероятность нечестности. В таких случаях записи транзакций, загруженные в рулон, становятся полезными, позволяя пользователям инициировать доказательства мошенничества.
• Для ZK Rollup доказательство с нулевым знанием доказало, что обновление состояния является правильным. Загрузка данных нужна только для того, чтобы пользователи могли самостоятельно рассчитать полное состояние. Когда узел уровня 2 не может работать правильно, включается механизм аварийного люка, который требует полного дерева состояний L2. Об этом мы поговорим в последнем разделе этой статьи.

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

Помещая данные о транзакциях в BLOB, хотя они и недоступны для контрактов, контракт основной сети может хранить обязательства BLOB.

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

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

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

Следует отметить, что в реальной работе Dencun для генерации обязательств не используется дерево Меркле, подобное Celestia, а применяется алгоритм KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment).

По сравнению с доказательством дерева Меркле, процесс создания KZG-доказательства относительно сложен, но его объем проверки меньше, а этапы проверки проще. Однако недостатком является то, что он требует доверительных настроек (ceremony.ethereum.org, который уже закончился) и не способен предотвратить атаки квантовых вычислений (Dencun использует метод Version Hash, а другие методы проверки могут быть заменены при необходимости).

Для популярного сейчас DA-проекта Celestia используется вариант дерева Меркла. В отличие от KZG, она в некоторой степени полагается на целостность узлов, но помогает снизить порог вычислительных ресурсов между узлами, сохраняя децентрализованную природу сети.

03. Возможности в Денкуне

Хотя EIP-4844 снижает затраты и повышает эффективность Layer 2, он также повышает риски безопасности, что также открывает новые возможности.

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

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

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

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

Это то, что Виталик часто называет атакой с сокрытием данных.

До появления EIP-4844 постоянные записи уровня 2 записывались в основной сети. Когда ни один узел уровня 2 не может обеспечить полный статус вне цепи, пользователи могут сами развернуть полноценный узел.

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

После EIP-4844 данные уровня 2 будут храниться только в BLOB на полных узлах Ethereum, а исторические данные за 18 дней будут автоматически удалены.

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

После введения в эксплуатацию EIP-4844 пользователям будет очень сложно получить полное дерево состояния уровня 2 абсолютно достоверным способом.

Без стабильного способа получения пользователями дерева состояний Уровня 2 они не смогут выполнять операции принудительного вывода в экстремальных условиях. Поэтому EIP-4844 в определенной степени стал недостатком безопасности на Уровне 2.

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

Ethstorage может решить проблему отсутствия доверия и уже получил два раунда финансирования от Ethereum Foundation.

На самом деле, эта концепция может по-настоящему реализовать потенциал, заложенный в обновлении Dencun, и она достойна нашего внимания.

Наиболее интуитивно понятное значение Ethstorage заключается в том, что он может увеличить время доступности DA BLOB полностью децентрализованным способом, компенсируя недостатки безопасности второго уровня после EIP-4844.

Кроме того, большинство существующих решений L2 в основном направлены на масштабирование вычислительной мощности Ethereum, т.е. на увеличение TPS. Однако спрос на безопасное хранение больших объемов данных в сети Ethereum резко возрос, особенно благодаря популярности таких dApp, как NFT и DeFi.

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

Наконец, Ethstorage также может решить внешние потребности децентрализованных dApps. В настоящее время существующие решения в основном размещаются на централизованных серверах (с DNS). Такая настройка делает сайты уязвимыми для цензуры и других проблем, таких как взлом DNS, взлом сайтов или падение серверов, о чем свидетельствуют такие инциденты, как Tornado Cash.

Ethstorage все еще находится на стадии начального тестирования, и пользователи, которые с оптимизмом смотрят на перспективы этого трека, могут попробовать его.

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

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