Глубокий анализ эпохи после обновления Канкуна: данные и инвестиционный взгляд

Введение

С момента официального запуска Ethereum 30 июля 2015 года прошло 12 обновлений, каждое из которых привлекало большое внимание.

Основная цель этого обновления Ethereum Cancun-Deneb ( Dencun ) заключается в повышении масштабируемости и модульности сети Layer 2, усилении функций безопасности сети Ethereum и улучшении общей удобства.

1. Что такое обновление Dencun

1.1 Введение в обновление

1.1.1 Происхождение названия

Эфирная база состоит из двух частей, которые объединены: уровень выполнения и уровень консенсуса, каждая из этих частей имеет свои правила именования.

Правила именования обновлений уровня начали действовать с 2021 года и основываются на городах, где проводилась конференция разработчиков Ethereum Devcon(. Например, обновление Берлин, обновление Лондон, обновление Шанхай и т.д.

Правила именования обновления уровня консенсуса с момента запуска цепи Beacon основаны на именах небесных тел и следуют алфавитному порядку. Например, Вега) Альтаир(, Бетельгейзе) Беллатрикс(, Капелла) и т.д.

Каждое обновление Ethereum называется комбинацией различных названий обновлений, формируя общее название обновления. Поскольку место проведения Devcon находится в Канкуне, Мексика, а обновление уровня консенсуса называется Deneb, текущее обновление Ethereum сокращенно называется обновлением Dencun.

1.1.2 Фон обновления

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

С одной стороны, согласно плану, опубликованному основателем Ethereum Виталиком Бутериным 31 декабря 2023 года, обновление Dencun соответствует части The surge, начиная с приоритета пользовательского опыта (, например, повышения скорости транзакций, снижения Gas fee ), с целью повышения эффективности сети, снижения затрат на транзакции и создания прочной основы для будущего развития.

С другой стороны, из статьи Виталика Бутерина «Сделаем Эфириум снова киберпанком», опубликованной 28 декабря 2023 года, становится известно, что Виталик считает одной из основных причин, по которой блокчейн становится все более ограниченным в сфере спекуляций с активами, рост транзакционных сборов. Это приводит к тому, что «Degen Gamblers» становятся основной группой, что препятствует реализации прикладной ценности блокчейна, поэтому необходимо снизить транзакционные сборы.

1.1.3 Время обновления

Согласно плану Ethereum, время обновления и информация об активации:

• Время активации обновления уровня исполнения (EL): 13,843,136 высота
• Уровень консенсуса (CL) время активации обновления: Эпоха 269568

1.1.4 Содержимое

Ethereum Cancun-Deneb внес ряд улучшений в уровень исполнения и уровень консенсуса соответственно, а в Cancun (Cancun) улучшен уровень исполнения (EL). Deneb (Deneb) укрепляет уровень консенсуса (CL), Он также включает в себя ряд ( EIP) предложений по улучшению Ethereum, которые имеют решающее значение для развития сети Ethereum. Всего существует 9 EIP, и мы представим ключевые EIP позже.

(# 1.2 Основные моменты обновления Dencun

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

1.2.1 EIP-4844 Шардированные Blob транзакции ) Proto-Danksharding ###

EIP-4844 является главной особенностью этого обновления, направленным на снижение комиссий, увеличение пропускной способности ( TPS ) и расширяемости. Его суть заключается в переходном обновлении, подготовке к будущему, чтобы осуществить полное Danksharding (, последнюю часть обновления "Спокойствие" Ethereum ), Proto-Danksharding закладывает основу для Danksharding.

Предоставление доступности данных на основной цепи Ethereum можно понять как данные Calldata(, которые возникают в результате вызовов контрактных транзакций ), а данные, возвращаемые Layer 2 на Layer 1, хранятся в Calldata. Кроме того, для безопасности каждое выполнение Calldata требует Gas, что приводит к высокой стоимости Gas. Однако после проверки данных транзакций в Calldata на самом деле они не имеют большого значения, данные за длительный период также могут быть загружены для проверки, даже не нужно передавать их на уровень выполнения. Например, на основе исторического распределения средних транзакционных сборов Layer2-OP можно увидеть, что почти 80% сборов приходятся на сборы данных L1.

Таким образом, EIP-4844 вводит новую структуру хранения данных — Blob, специально предназначенную для хранения данных о транзакциях, отправляемых с L2 на L1. После введения данные о транзакциях L2 напрямую отправляются в Blob для хранения, доступного для полного скачивания узлами консенсуса, и могут быть удалены всего через короткую задержку, что снижает ненужную нагрузку на хранение. Это означает, что введение Blob значительно снизит транзакционные сборы L2. Кроме того, Blob фактически предоставляет дополнительное пространство в блоке для L2, что также значительно увеличит пропускную способность транзакций L2.

1.2.2 EIP-1153 Операционный код временного хранения

Основная цель EIP-1153 - сократить объем хранимых данных и затраты на хранение. Временное хранилище уничтожается после каждой транзакции, поэтому временное хранилище дешевле, поскольку не требует доступа к диску.

EIP-1153 более дружелюбен к разработчикам Dapp, вводя в EVM новые операционные коды TSTORE и TLOAD, стоимость газа для вызова этих операционных кодов составляет примерно 100 Gas за каждую операцию, что на 95% дешевле, чем традиционные вызовы хранения (SLOAD и SSTORE). В то же время, как только выполнение полного транзакции завершено, эта часть хранилища будет очищена, что снизит затраты на хранение и потребление газа, например, в будущем это может позволить новым DeFi контрактам экономить газ.

1.2.3 EIP-4788 Корень сигнала блока в EVM

EIP-4788 реализует коммуникацию между EVM( Эфириум виртуальной машиной) и Beacon( цепочкой сигналов). Эта функция поддерживает различные случаи использования, может улучшить пулы стейкинга(, конструкции повторного стейкинга), смарт-контрактные мосты(, MEV и другие.

Ранее EVM не мог непосредственно получать данные и состояние Beacon, и мог только захватывать состояние через внешние доверенные оракулы. Поэтому было предложено размещать корень родительского сигнального блока )parent_beacon_block_root( в каждом блоке EVM, чтобы при обновлении Beacon EVM мог немедленно получать точную информацию.

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

1.2.4 EIP-5656 MCOPY - Инструкция копирования памяти

EIP-5656 оптимизирует процесс копирования областей памяти, вводя новую инструкцию EVM MCOPY, что повышает эффективность перемещения данных в EVM.

Копирование памяти является базовой операцией, но его реализация на EVM приводит к накладным расходам. Например, копирование 256 байт данных памяти, разработчики могут значительно снизить затраты с 96 Gas) при использовании MLOAD и MSTORE( до 27 Gas с помощью операции MCOPY. Ожидается, что в будущем большинство разработчиков будет использовать MCOPY вместо MSTORE/MLOAD, а более эффективные Gas контракты в конечном итоге также принесут выгоду конечным пользователям.

В то же время MCOPY заполнил пробелы в методах копирования памяти в EVM.

1.2.5 EIP-6780 SELFDESTRUCT только в той же транзакции

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

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

) 2. Влияние на данные после обновления

(# 2.1 Влияние газа

Основной аспект этого обновления, который наиболее волнует всех, связан с изменением Gas-費. Благодаря введению EIP-4844 наиболее заметную выгоду получает уровень Layer 2, где снижение Gas-費 очень очевидно, что улучшает пользовательский опыт. Это в основном соответствует ожидаемому снижению сборов Layer 2 на 90% до обновления.

Что касается Layer1) самого Ethereum (, то после обновления Gas-стоимость несколько снизилась, но не значительно, пользователи на самом деле не заметили изменений в использовании.

![Глубокий анализ эпохи после обновления Канкуна: данные и инвестиционный взгляд])https://img-cdn.gateio.im/webp-social/moments-f17426dc632c755745ea71b3d5f3c2aa.webp###

2.2 Влияние объема торговли

Помимо снижения Gas, обновление также направлено на повышение пропускной способности, что является ключевым аспектом плана расширения Ethereum.

После завершения обновления объем торгов на Base резко увеличился и преодолел прежний барьер, поднявшись с 500 000 до 2 миллионов, что означает, что EIP-4844 оказал на него непосредственное влияние, и выгода была наиболее очевидной.

(# 2.3 Влияние TPS

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

После завершения обновления TPS для каждого Layer2 в основном увеличился, но максимум не превышает 30 транзакций в секунду.

Низкий TPS является общей проблемой в текущей отрасли Web3, в отличие от высокой характеристике TPS в традиционной отрасли Web2. Максимальный TPS Layer2 также не превышает 500, но с точки зрения развития отрасли, это обновление закладывает основу для будущего, а также отвечает ожиданиям развития Ethereum ------ достичь более 100000 TPS.

2.4 Использование Blob

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

Изначально предполагалось, что если реализовать среднюю цель в 3 Blob на блок, пропускная способность L2 увеличится почти в 2 раза. Если в конечном итоге будет достигнута цель в 64 Blob на блок, пропускная способность L2 увеличится почти в 40 раз. Максимальный лимит для этого обновления установлен на 6 Blob.

Согласно текущей ситуации, Blob уже начал использоваться в торговле, но общий уровень использования не так высок, максимальная отметка также была зафиксирована сразу после завершения обновления, а затем постепенно снизилась, и пока не достигла ожидаемой средней цели в 3 Blob.

Однако внедрение типа Blob действительно значительно улучшает затраты на данные Layer2 на Layer1. Из примера с цепочкой OP, упомянутого выше, можно наглядно увидеть, что затраты на данные, использующие L1, в среднем по транзакциям Layer2 заметно снизились, практически исчезли, что также с другой стороны позволяет предположить, что прибыльность Layer2 может увеличиться.

Модель прибыли L2 относительно проста и ясна, ее можно свести к следующему: цепочечная прибыль = торговые сборы L2 - стоимость платежей L1; на примере цепи OP, хотя обновление одновременно снизило торговые сборы L2 и стоимость платежей L1, из-за роста объема сделок и базы пользователей снижение обоих показателей абсолютно не сопоставимо. Торговые сборы снизились с сотен тысяч до десятков тысяч, в то время как стоимость платежей снизилась с сотен тысяч до менее 1k, и цепочечная прибыль также увеличилась после обновления.