Приближается обновление Ethereum Cancun, обзор прошлого, настоящего и будущего обновления Cancun

Добавить Автора

прошлые жизни

Зачем нужен апгрейд Cancun?

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

Проблемы с Эфириумом:

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

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

Чтобы решить трилемму безопасности, децентрализации и масштабируемости, Ethereum использовал механизм PoW-to-PoS для дальнейшего снижения порога узла, а также планирует использовать цепочку маяков для случайного назначения верификаторов для оптимизации безопасности. масштабируемости Ethereum рассматривает возможность использования сегментирования для снижения нагрузки на узлы, что также позволяет Ethereum создавать несколько блоков одновременно и повышать масштабируемость.

В настоящее время пространство каждого блока Ethereum составляет около 200–300 КБ, минимальный размер каждой транзакции составляет около 100 байт, около 2000 транзакций, разделенных на время блока 12 секунд, верхний предел TPS Ethereum ограничен около 100 . Эти данные явно не могут удовлетворить потребности Ethereum.

Следовательно, уровень 2 Ethereum фокусируется на том, как поместить большой объем данных в блочное пространство и обеспечить безопасность с помощью доказательств мошенничества и доказательств достоверности.Вот почему уровень DA определяет верхний предел безопасности, который также является основным содержанием Обновление Канкуна.

Итеративный маршрут экологии Ethereum не может обеспечить производительность эталонного теста Solana (с точки зрения задержки и пропускной способности), а производительность фрагментации Near не будет замечена в краткосрочной перспективе, равно как и производительность параллельного выполнения Sui и Aptos. В краткосрочной перспективе Ethereum может построить многоуровневую структуру только с Rollup в качестве ядра, поэтому обновление Cancun для решения TPS, платы за газ и опыта разработчиков имеет решающее значение для дорожной карты Ethereum.

Как планируется дорожная карта Ethereum?

Недавние важные обновления и их цели

1 декабря 2020 года сеть маяков была официально выпущена, что открыло путь для обновлений POS.

Лондонское обновление 5 августа 2021 года, EIP1559 изменило экономическую модель Ethereum;

15 сентября 2022 г. парижское обновление (TheMerge) завершило переход POW на POS;

12 апреля 2023 г. Шанхай был модернизирован для решения проблемы снятия залога;

Экономическая модель и обновления, связанные с POS, были завершены, и следующие несколько обновлений решили проблемы производительности Ethereum, TPS и опыта разработчиков;

Следующий шаг сосредоточен на TheSurge в дорожной карте Ethereum.

Цель: достичь 100 000+ TPS в Rollup.

В основном есть 2 решения, ончейн и офчейн:

Решение вне сети: относится к Layer2, включая объединение и т. д.

Схема в цепочке: относится к внесению изменений непосредственно в L1, что является популярной схемой шардинга.Простое понимание шардинга состоит в том, чтобы разделить все узлы на разные области и выполнить задачи каждой области, что эффективно увеличит скорость;

Анализ схемы фрагментации:

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

Danksharding — это новый дизайн сегментирования, предложенный для Ethereum. Его основная идея — централизованная генерация блоков + децентрализованная проверка + устойчивость к цензуре.Это также связано с выборкой доступности данных (DAS) и производителями блоков, упомянутыми ниже. Связанные устойчивые списки (Crlist). Наибольшее значение основной идеи Danksharding заключается в том, чтобы превратить Ethereum L1 в единый уровень расчетов и доступности данных (DataAvailability).

Схема шардирования разделена на этапы 2. В настоящее время она делится на Proto-danksharding и Fully-Rollup.

Прото-данкшардинг:

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

Содержание: основной особенностью прото-данкшардинга является введение нового типа транзакций больших двоичных объектов. Большие двоичные объекты обладают характеристиками большой емкости и низкой стоимости. Добавление таких пакетов данных в Ethereum может позволить хранить все сводные данные в больших двоичных объектах, что значительно снижает хранение основного давления цепи, но и снизить стоимость свертки.

Полный накопитель

Введение: Rollup полностью расширяет емкость, фокусируясь на использовании доступных данных.

содержание:

P2P-дизайн DAS: Некоторые работы и исследования, связанные с проблемой подключения к сети с разделением данных;

Клиент выборки доступности данных: разработка облегченного клиента, который может быстро определить, доступны ли данные, путем случайной выборки нескольких килобайт;

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

Встреча разработчиков Ethereum Core

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

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

Основной процесс: процесс обновления, основанный на EIP, примерно выглядит следующим образом: сначала EIP первоначально принимается на основной конференции разработчиков (сокращенно ACD), а затем команда клиента тестирует его независимо от того, включен ли EIP в обновление. После финального теста просмотрите его еще раз, а затем решите, включать ли его в реальное обновление на основе обсуждения.

Существует два типа собраний, а именно собрание уровня консенсуса и собрание исполнительного уровня, которые проводятся попеременно раз в две недели:

Consensus Layer Conference (Консенсус разработчиков AllCore — ACDC), посвященный консенсусному уровню Ethereum (Proof of Stake, Beacon Chain и т. д.);

Конференция исполнительного уровня (решение AllCore Developers — ACDE), посвященная исполнительному уровню Ethereum (EVM, расписание газа и т. д.).

Существует три типа основных сопровождающих Ethereum, в основном это официальные организации или форумы добровольцев, на которых обсуждаются предложения:

AllCoreDevs: специалисты по сопровождению кода, отвечающие за сетевой клиент ETH1, обновление, поддержку кода Ethereum и базовой архитектуры;

Раздел «Управление проектами»: поддержка разработчиков Ethereum, координация хардфорков, мониторинг EIP и т. д., а также прямая помощь AllCoreDevs в общении и операциях;

EthereumMagicians: «Форум» для обсуждения EIP и других технических тем.

Хронология встреч, связанных с эскалацией в Канкуне

Согласно содержанию обсуждения, эту модернизацию Канкуна можно условно разделить на пять этапов.

Первый этап - введение темы апгрейда

Представляем новые задачи proto-danksharding, EOF и коды операций «самоуничтожение», кратко обсуждаем контент Шанхайского обновления.

После того, как слияние Ethereum было завершено 15, 22 сентября, собрание разработчиков было приостановлено на 4 недели, что позволило разработчикам проверить EIP, обсуждаемый в последующем обновлении, в течение одного месяца;

28 и 22 октября на первой встрече разработчиков после слияния впервые была предложена реализация прото-данкшардинга, EOF и опкода «самоуничтожение». некоторые разработчики изначально считают, что шанхайское обновление можно разделить на несколько небольших обновлений, например, сначала включить обещанный вывод ETH, а затем обновить EIP4844, но некоторые разработчики считают, что более целесообразно реализовать более крупное обновление за один шаг.

Фаза 2 - Определение временных рамок и подготовка к церемонии КЗГ

В конце 2022 года конференция Ethereum будет в основном посвящена EOF и EIP4844. В то же время мы продолжим продвигать предварительную церемонию установки, требуемую EIP4844 - церемонию KZG. Разработчики официально определят, в каком обновлении 4844 будет появится 23 января

22 ноября EOF или прото-данкшардинг упоминался на телефонной конференции всех основных разработчиков Эфириума № 149. В настоящее время разработчики все еще рассматривают возможность его размещения в шанхайском обновлении;

На совещании уровня консенсуса 02.12.22 Трент Ван Эппс, глава экосистемы Ethereum, проинформировал о ходе церемонии доверенной настройки, необходимой для реализации EIP4844, целью которой является создание фрагмента безопасного кода, который будет используется в EIP4844. VanEpps надеется, что церемония станет одной из крупнейших в криптопространстве, собрав от 8 000 до 10 000 взносов.Период публичного взноса на церемонию продлится около 2 месяцев и начнется где-то в декабре;

На собрании основных разработчиков в тот же день было некоторое обсуждение вокруг EOF и деактивации опкода самоуничтожения.Некий разработчик Ethereum Foundation возражал против переноса EOF в Канкун, утверждая, что если изменения кода не будут включены в Шанхай, это войдетВозможность Канкуна очень мала.Что касается кода самоуничтожения, некоторые разработчики в то время выступали за продвижение EIP4758, но прямое отключение этого кода операции нарушит работу некоторых приложений.Разработчики считают, что перед созданием пограничного случая для защиты этого типа контракта, Этот EIP следует снова взвешивать в течение определенного периода времени;

На собрании основных разработчиков 9 декабря 22 года было предложено провести церемонию KZG в отношении обновления в Канкуне.В настоящее время заслуживающая доверия церемония настройки, требуемая EIP4844, готова;

На совещании уровня консенсуса 16.12.22 по теме EIP4844 разработчики обсудили объединение двух разных запросов на включение (PR) в спецификацию для прото-данкшардинга, один из которых связан с тем, как узлы обрабатывают данные, вырезанные из одного, заключается в том, что при отсутствии информации о блобах на каком-то блоке в ноды оповещения будет введен новый код ошибки;

На собрании основных разработчиков 5 23 января разработчики пришли к консенсусу по поводу удаления модификаций кода, связанных с реализацией EOF, из шанхайского обновления. В это время Beiko предложила решить, следует ли включать EOF в препятствие через две недели. Кун совершенствуется;

Этап 3 – Предварительное обсуждение объема предложения

В конце 23 января EOF был перемещен в Канкун для обновления после удаления из Шанхая. В следующие два месяца обсуждения в основном были сосредоточены на других предложениях, кроме EOF и EIP4844. В то же время EOF было предложено переехать из Канкуна. . Этот период времени в основном был потрачен на определение объема предложений по модернизации Канкуна.

На собрании основных разработчиков 20 и 23 января EOF был перемещен в Канкун для обновления;

На основной встрече разработчиков 6 марта 23 года предварительные предложения по обновлению в Канкуне были следующими: EIP4788 (общедоступный корень состояния цепи маяков), EIP2537 (эффективное выполнение таких операций, как проверка подписи BLS и проверка SNARK), EIP-5920 (введение нового код операции PAY) и комбинированная реализация EIP6189 (для обеспечения совместимости SELFDESTRUCT с деревьями Verkle) и EIP-6190 (изменение функции SELFDESTRUCT, чтобы вызвать только ограниченное количество изменений состояния);

На основной встрече разработчиков 16, 23 марта помимо EOF и EIP4844 были рассмотрены следующие предложения для включения в Канкун: формат SSZ, удаление SELFDESTRUCT, EIP2537, EVMMAX, EIP1153, неограниченные инструкции SWAP и DUP, введение PAY Beacon состояние root в коде и EVM;

На собрании основных разработчиков 30 марта 23 года впервые было выдвинуто предложение EIP-6780 по отключению SELFDESTRUCT, которое также является предложением по отключению SELFDESTRUCT, которое Канкун наконец решил использовать. Но что касается реализации EOF, разработчик из клиентской группы Erigon (EL) заявил, что EOF «слишком сильно изменился», чтобы его можно было объединить с предложением по улучшению Ethereum EIP4844 в предстоящем обновлении Cancun, которое было предложено обновить в Cancun Implement. EOF в хардфорке вскоре после этого;

Четвертый этап - определить четкое направление обновления предложения и удалить неактуальные предложения

23 апреля было четкое направление для предложений, которые должны быть охвачены обновлением Канкун.Ключевым узлом была встреча разработчиков 13 апреля.На этой встрече было предложено 9 EIP, и сам Тим также имел более глубокое понимание альтернативные предложения. Обсуждение на встрече 27 апреля EIP6780, EIP6475 и EIP1153 было решено включить в Канкун, в то время как EOF и EVMMAX (подмножества EIP, связанные с реализацией EOF) были удалены из обновления Канкуна, обновление EOF может в основном помочь Управление версиями EVM и несколько наборов правил контрактов могут выполняться одновременно, что способствует последующему расширению Ethereum.Однако, учитывая осуществимость всего обновления, обновление EOF может продвигаться с ежедневными обновлениями в последующем. вверх

12, 23 апреля завершился апгрейд Ethereum Shanghai;

В дополнение к основной встрече разработчиков 13.04.23, где разработчики обсудили EIP4844 (для предоставления данных о корневом состоянии CL в EL), для обновления рассматриваются как минимум девять других EIP, это EIP4844, удаление SELFDESTRUCT ( EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIPs (EIP6601 и EIP6690), изменения SSZ (EIP6475, EIP6493, EIP 6465, EIP6404 и EIP6466), E IP5656 и EIP6193;

На основной встрече разработчиков 27 и 23 апреля были сосредоточены на нескольких прогрессах и компромиссах. Во-первых, EIP4844 по-прежнему идентифицируется для включения в обновление Cancun, в то время как были добавлены следующие EIP: EIP6780 (изменение функциональности кода операции SELFDESTRUCT), EIP6475 (новый тип Simple Serialization (SSZ) для представления необязательных значений), EIP1153 ( добавляет новое, во-вторых, EIP, которые рассматриваются, но официально не включены в обновление: EIP6913 (введение инструкции SETCODE), EIP6493 (определение схемы подписи для транзакций, закодированных SSZ), EIP4788 (раскрытие корня цепочки маяков в блоке EL заголовок), EIP2537 (добавляет кривую BLS12-381 в качестве предварительной компиляции) и EIP5656 (вводит новые инструкции EVM для копирования областей памяти); наконец, EOF и EVMMAX (подмножество EIP, связанное с реализацией EOF) были удалены из обновления Cancun. Обновление EOF было удалено из шанхайского обновления на конференции разработчиков Ethereum в начале января 2023 г., и по умолчанию оно отображалось в обновлении в Канкуне с конца января 2023 г. по начало апреля 2023 г., но разработка 29, 23 апреля EOF снова удаляется во время собрания авторов.

Пятый этап - окончательное определение предложения и доработка деталей

23 мая окончательные детали предложения были в основном оптимизированы и улучшены.Изменение SSZ->RLP будет означать, что два SSZEIP в Канкуне больше не понадобятся, поэтому EIP6475 и 6493 будут перемещены из Канкуна для обновления. Также на собрании 26-го Тим Бейко предложил, чтобы будущие разговоры о расширении масштабов Канкуна ограничивались следующими пятью EIP: EIP-5920, 5656, 7069, 4788 и 2530. Теперь разработчики определили полную степень обновления Cancun.

Консенсусное собрание Ethereum Core 5 мая 23 года обсудило EIP4788, который упоминался в последний раз, и добавило обсуждения EIP6987 и EIP6475, которые касаются валидаторов и транзакций SSZ соответственно;

На 161-м заседании исполнительного уровня Ethereum 11 мая 23 года ТимБейко сказал, что объем обновления Канкун все еще может быть изменен в ближайшие несколько недель, но если от разработчика не будет четкого предложения, объем обновления Канкун будет изменен. Сохраните статус «по умолчанию», и обсуждение EIP-4844 показывает, что разработчики согласны удалить SSZ из реализации EL EIP-4844, но это не повлияло на дальнейшее продвижение 6475. В дополнение к этому разработчики также кратко обсудили два EIP для рассмотрения в Канкуне, а именно EIP6969 (модифицированная версия EIP1559) и EIP5656 (эффективные инструкции EVM для копирования областей памяти);

Разработка 4844 была кратко обсуждена на собрании разработчиков консенсуса 18.05.23, например, разрешение приложениям смарт-контрактов на EL проверять доказательства состояния CL;

Деактивация SELFDESTRUCT, изменения спецификации EIP-4844, управление кодами операций и возможные возможные дополнения в Канкуне обсуждались на 162-м собрании Ethereum Core 25 мая 2023 года. Тим Бейко предложил, чтобы будущие разговоры о расширении масштабов Канкуна ограничивались следующими пятью EIP: EIP-5920, 5656, 7069, 4788 и 2530. Застройщик определит полный спектр Dencun (Deneb+Cancun) в ближайшие несколько недель;

На 110-й конференции Ethereum Consensus Layer 1 июня 2023 года исследователь из Ethereum Foundation представил результаты эксперимента с данными о способности узлов основной сети Ethereum распространять большие объемы данных.Из этого результата исследователь предположил, что EIP4844 спецификация увеличена с максимум 4 больших двоичных объектов до 6 на блок. В то же время разработчики рассматривают возможность включения EIP4788 в обновление Cancun;

На основном собрании разработчиков 13 июня 2023 г. разработчики официально подтвердили объем обновления, включая EIP4844, EIP1153, EIP5656, EIP6780 и EIP4788;

На консенсусной встрече 15 июня 2023 г. было обсуждено, какие EIP, ориентированные на CL, следует включить в Deneb, среди которых было предложено добавить EIP-6988, EIP-7044, EIP-7045, и команда клиента CL согласовала Следующее Протестируйте увеличившееся количество блобов на тестовой сети EIP-4844 Devnet6 и примите окончательное решение по этому поводу в течение двух недель.В то же время Майкл Нойдер, исследователь Ethereum Foundation, предложил отменить 32 ETH. ограничение залога, чтобы помочь уменьшить рост активного набора валидаторов;

На встрече 22 июня 2023 года Тим предложил переместить прекомпилированный адрес 4844 в 0xA, запаковать их и перенести BLS на другой адрес, хотя этот прекомпилированный был введен через EIP2537, он не будет учитываться в Канкунском плане;

На консенсусном совещании 29 июня 2023 г. разработчики продолжили обсуждение количества BLOB-объектов, увеличили целевой лимит BLOB-объектов с 2 до 3 и повысили максимальный лимит BLOB-объектов с 4 до 6. В то же время тестовая сеть 4844 Devnet №7 будет запущен в ближайшее время.

эта жизнь

Основной контент — EIP4844, Proto-Danksharding.

Окончательные диапазоны EIP для обновления Cancun: EIP4844, EIP1153, EIP5656, EIP6780 и EIP4788. В то же время на 111-м заседании Ethereum ACDC 19 июня разработчики продолжили обсуждение EIP6988, EIP7044 и EIP7045 для включения в Deneb. Разработчики заявили, что планируют объединить три вышеупомянутых EIP в спецификацию Deneb в ближайшие недели.

Анализ ключевых EIP

EIP4844

Введение:

Название предложения EIP4844 — Proto-Danksharding, которое представляет собой решение для предварительного сегментирования полной версии Danksharding, Весь набор схем сегментирования фактически вращается вокруг Rollup для расширения в сети. Цель решения — расширить Rollup уровня 2, помогая L2 снизить комиссию и увеличить пропускную способность, одновременно прокладывая путь к полному сегментированию.

На телефонной конференции 23 февраля разработчики Ethereum обновили EIP4844 и назвали его Deneb, что является именем первоклассной звезды в Лебеде, то есть имя EIP4844 в соответствующей версии GitHub будет обновлено до Deneb в будущее; На встрече 1 марта были внесены некоторые изменения в следующую спецификацию обновления Ethereum, которая называется Deneb на стороне CL и Cancun на стороне EL;

На собрании разработчиков 23 июня разработчики собирались обновить предварительно скомпилированный адрес EIP4844. В настоящее время основные разработчики добавили в EVM 9 прекомпиляторов и создадут два прекомпилятора с адресами «0xA» и «0xB», активировав EIP4844 и 4788 соответственно. На консенсусной встрече 29 июня была подготовлена Devnet # 7, выделенная краткосрочная тестовая сеть для EIP4844.

EIP-4844 вводит совершенно новый тип транзакции — BlobTranscation.

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

Blob, как и подключаемый пакет данных, имеет только пространство для хранения 128 КБ в начале. В начале обсуждения предложения цель и предел Blob были 2/4. На собрании разработчиков 9 июня , 23, он был скорректирован до 3/6. То есть в настоящее время каждая транзакция в Ethereum может содержать до трех транзакций Blob, что составляет 384 КБ, а емкость targetBlob каждого блока составляет 6, что составляет 768 КБ, и может содержать максимум 16 транзакций Blob, что составляет 2 МБ;

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

Blob использует KZGcommit Hash как Hash для проверки данных, аналогично Merkle;

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

Роль Blob — улучшить TPS Ethereum при одновременном снижении затрат

В настоящее время общий объем данных всего Ethereum составляет всего около 1 ТБ, а Blob может ежегодно приносить в Ethereum 2,5-5 ТБ дополнительного объема данных, что напрямую превышает сам леджер в несколько раз;

Для узлов загрузка от 1 МБ до 2 МБ данных BLOB-объектов на блок не вызовет нагрузки на пропускную способность, а пространство для хранения только увеличит фиксированный объем данных BLOB-объектов примерно на 200–400 ГБ в месяц, что не повлияет на децентрализацию всей системы. Узел Ethereum, но расширение вокруг Rollup значительно улучшено;

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

Роль EIP-4844 — открытие первой главы повествования о Danksharding

Высокое расширение: в настоящее время EIP-4844 может первоначально увеличить емкость L2.Полная версия Danksharding может увеличить объем данных Blob в EIP-4844 с 1 МБ до 2 МБ, с 16 МБ до 32 МБ.Высокое расширение;

Низкие комиссии: по мнению аналитиков bernstein, Proto-dank-sharding может снизить комиссию сети уровня 2 в 10-100 раз по сравнению с текущим уровнем;

Фактические данные:

В тестовой сети Opside было развернуто 4844 сети, и текущее наблюдение может снизить стоимость развертывания на 50 %;

Техническое решение EigenLayer DA не раскрывает слишком много для оценки своих данных;

Строго говоря, Celestia имеет мало общего с Ethereum, и стоимость ее DA сейчас не может быть оценена в зависимости от конкретных технических решений;

Решение Ethstorage состоит в том, чтобы загрузить свой сертификат хранилища уровня 2, и его стоимость DA может быть снижена до 5% от первоначальной;

Topia рассчитывает снизить затраты в 100–1000 раз, поскольку основная сеть Danksharding также должна учитывать безопасность и совместимость с широковещательной сетью P2P уровня 1.

Решение DA: Danksharding (решение для расширения Ethereum) в настоящее время может иметь проблемы с чрезмерной нагрузкой на узлы (более 16 МБ) и недостаточной доступностью данных (срок действия 30 дней), если оно продолжит расширяться. Решение:

DataAvailability Sampling — снижает нагрузку на узлы

Разрежьте данные в блобе на фрагменты данных и позвольте узлам перейти от загрузки данных блоба к случайной проверке фрагментов данных блоба, чтобы фрагменты данных блоба были разбросаны по каждому узлу Ethereum, а полные данные блоба были сохранены. во всей бухгалтерской книге Ethereum In Fang предполагается, что количество узлов должно быть достаточным и децентрализованным;

DAS использует две технологии: кодирование стирания (ErasureCoding) и полиномиальное обязательство KZG (KZGCommitment);

Разделение «предлагающий-упаковщик» (PBS) — решает проблему разделения труда между узлами, позволяя узлам с высокопроизводительными конфигурациями отвечать за загрузку всех данных для кодирования и распространения, а узлам с низкопроизводительными конфигурациями — за выборочные проверки. и проверки.

Узлы с высокопроизводительными конфигурациями могут стать сборщиками.Сборщикам нужно только загружать данные BLOB-объектов для кодирования и создания блоков, а затем передавать их на другие узлы для выборочной проверки.Строители, поскольку требования к объему данных синхронизации и пропускной способности высоки, будут относительно централизованный;

Узел с конфигурацией низкой производительности может стать предлагающим (Proposer).Предлагающему нужно только проверить достоверность данных и создать и транслировать заголовок блока (BlockHeader).Однако для предлагающего (Proposer) количество синхронных данных Требования к пропускной способности относительно высоки. Низкие, поэтому он будет децентрализован.

Список антицензуры (crList) — решает проблему, связанную с тем, что упаковщики могут намеренно игнорировать определенные транзакции и вставлять транзакции, которые они хотят получить MEV, из-за их чрезмерной проверки.

Прежде чем построитель (Builder) упаковывает транзакции блока, предлагающий (Proposer) сначала публикует устойчивый к просмотру список (crList), который содержит все транзакции в мемпуле;

Строитель (Builder) может выбрать упаковку и сортировку транзакций только в crList, что означает, что строитель не может вставить свою собственную частную транзакцию для получения MEV, а также не может намеренно отклонить транзакцию (если лимит газа не заполнен);

После упаковки Builder транслирует окончательную версию Hash списка транзакций Proposer, и Proposer выбирает один из списков транзакций для генерации заголовка блока (BlockHeader) и транслирует его;

Когда узел синхронизирует данные, он получает заголовок блока от предлагающего (Proposer), а затем получает тело блока от упаковщика (Builder), чтобы гарантировать, что тело блока является окончательной выбранной версией.

Двухслотовая PBS — решает проблему, с которой централизованные упаковщики становятся все более и более централизованными, приобретая MEV.

Используйте режим торгов для определения блока:

Построитель (Builder) создает заголовок блока списка транзакций после получения crList и ставок;

Предлагающий (Proposer) выбирает заголовок блока и строителя (Builder), которые в конечном итоге сделали успешную ставку, и предлагающий безоговорочно получает комиссию за выигравшую ставку (независимо от того, сгенерирован ли действительный блок);

Комитет по проверке (Комитеты) подтверждает заголовок выигрышного блока;

Строитель раскрывает тело выигрышного блока;

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

значение:

Во-первых, у построителя (Builder) больше возможностей для упаковки транзакций, но упомянутый выше crList, во-первых, ограничивает возможность временной вставки транзакций, а во-вторых, если построитель (Builder) хочет получить прибыль за счет изменения порядка транзакций, его необходимо заплатить большие затраты на торги в начале, чтобы гарантировать, что он может получить квалификацию главы блока, тогда получаемая им прибыль MEV будет дополнительно уменьшена, и в целом это повлияет на средства и фактическую стоимость получения МЭВ;

Однако на начальном этапе упаковщиками может стать лишь небольшое количество людей (учитывая проблемы с производительностью узла), тогда как большинство людей становятся только предоставителями, что может привести к дальнейшей централизации. small При определенных обстоятельствах некоторые опытные майнеры с возможностями MEV с большей вероятностью примут участие в торгах, что дополнительно повлияет на фактический эффект решения MEV;

Это имеет значение для некоторых решений MEV, использующих аукционы MEV.

значение:

EIP4844 на самом деле является очень упрощенной версией Danksharding: он предоставляет тот же интерфейс приложения, что и Danksharding, включая новый код операции DataHash и новый объект данных BinaryLarge Objects, который называется Blob;

proto-danksharding — это «скобочное» (то есть формат транзакций и правила проверки) предложение для реализации полной спецификации Danksharding: однако шардинг еще не реализован, и всем верификаторам и пользователям по-прежнему необходимо напрямую проверять наличие полных данных. ;

Почему вы выбираете proto-danksharding вместо EIP4488, чтобы напрямую снизить плату за уровень 2 в долгосрочной перспективе, потому что при обновлении до полного сегмента в будущем требуется лишь небольшая корректировка:

Основное практическое различие между EIP4488 и прото-данкшардингом заключается в том, что EIP-4488 пытается свести к минимуму изменения, которые Эфириум должен внести сегодня, в то время как прото-данкшардинг вносит больше изменений в Эфириум сегодня, чтобы перейти на Эфириум в будущем. требуется для шардинга полной версии;

Хотя реализация полного сегментирования (с выборкой доступности данных и т. д.) является сложной задачей, и после реализации прото-данкшардинга еще предстоит выполнить сложную работу, эти сложности будут контролироваться на уровне консенсуса. После развертывания proto-danksharding клиентской группе исполнительного уровня, разработчикам сводных пакетов и пользователям не нужно выполнять какую-либо дополнительную работу при переходе на полное сегментирование.

Для достижения полного сегментирования необходимо завершить фактическую реализацию PBS, делегированного доказательства и выборки доступности данных, но такие модификации будут сосредоточены на уровне CL, и разработчикам не нужно перенастраивать: в настоящее время 4844 реализует новый тип транзакции , который похож на Формат транзакции, логика перекрестной проверки консенсуса и логика уровня выполнения, необходимые для полного сегментирования, точно такие же, и также выводится самонастраивающееся независимое ценообразование газа для больших двоичных объектов. будущее, PBS и сертификаты делегирования должны быть завершены И фактическая реализация выборки доступности данных, но эти модификации только на уровне CL и не требуют модификаций разработчиками уровня EL или объединения, что удобно для разработчиков.

После удаления SELFDESTRUCTremoval EIP-6780 был окончательно определен как наиболее подходящее решение, но на собрании разработчиков 26-го числа Тим предложил добавить к этому предложению еще один код операции SETCODE, чтобы позволить программным учетным записям по-прежнему обновляться.

SELFDESTRUCTremoval EIP-6780：X

фон:

21 марта Виталик предположил, что SELFDESTRUCT приносит экологии Эфириума больше вреда, чем пользы, основная причина в том, что он единственный может изменять бесконечное количество объектов состояния в одном блоке, что приводит к изменению кода контракта, и может быть изменены без согласия учетной записи.Операционный код баланса учетной записи имеет большую скрытую опасность для безопасности Ethereum;

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

На основном собрании разработчиков 13 апреля 23 года для участия в обсуждении были представлены четыре предложения по САМОУНИЧТОЖЕНИЮ, а именно 6780, 4758, 6046 и 6190, а последующее предложение EIP6780 было определено как окончательное предложение.

Введение: самоуничтожение — это аварийная кнопка смарт-контракта, которая уничтожает контракт и переводит оставшиеся ETH на указанный счет.

EIP6780: отключите SELFDESTRUCT, если они не находятся в одной и той же транзакции в контракте.

ОБНОВЛЕНИЕ: 26 мая Тим предложил, помимо удаления SELFDESTRUCT, добавить еще один код операции — SETCODE, чтобы программные учетные записи по-прежнему могли обновляться. (То есть добавляется функция обновления, и свойство в смарт-контракте обновляется посредством update/upgrade.) Здесь поглощаются преимущества EIP4758, что позволяет dapp иметь место для апгрейда.

Причина: Манипулирование кодом САМОУНИЧТОЖЕНИЯ изначально требовало обширных изменений в состоянии учетной записи, таких как удаление всех кодов и хранилища. Это создает трудности для использования деревьев Verkle в будущем: каждая учетная запись будет храниться во многих разных ключах учетных записей, которые не будут явно связаны с корневой учетной записью.

ИЗМЕНЕНИЕ: этот EIP реализует изменение, которое удаляет САМОУНИЧТОЖЕНИЕ, за исключением следующих двух случаев.

Приложения, которые используются только для вывода средств из SELFDESTRUCT, по-прежнему будут работать;

SELFDESTRUCT, используемый в той же транзакции в контракте, также не нужно менять.

Значение: повысить безопасность

Раньше в основной сети был контракт, который использовал SELFDESTRUCT для ограничения того, кто может инициировать транзакции через контракт;

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

Три приведенных ниже предложения относятся к SELFDESTRUCT, которые впоследствии были удалены: 6780 был официально выбран на собрании основных разработчиков 28 и 23 апреля, а остальные три предложения были отклонены, поскольку команда разработчиков Ethereum в конечном итоге захотела полностью удалить код операции SELFDESTRUCT. и следующие три предложения более изменены путем замены.

EIP-4758 (УСТАРЕЛО): отключите SELFDESTRUCT, изменив SELFDESTRUCT на SENDALL, что восстанавливает все средства вызывающей стороне (отправляет весь эфир в учетной записи вызывающей стороне), но не удаляет какой-либо код или хранилище.

Причина: как и выше, ранее манипулирование кодами САМОУНИЧТОЖЕНИЯ требовало значительных изменений в состоянии учетной записи, таких как удаление всех кодов и хранилища. Это создает трудности для использования деревьев Verkle в будущем: каждая учетная запись будет храниться во многих разных ключах учетных записей, которые не будут явно связаны с корневой учетной записью.

Изменять:

Опкод SELFDESTRUCT переименован в SENDALL, теперь только перемещает все ETH в аккаунте вызывающей стороне, схема больше не нарушает код и хранилище или не изменяет одноразовые номера;

Все связанные возвраты SELFDESTRUCT были удалены

значение:

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

EIP-6046 (устарело): заменить SELFDESTRUCT на DEACTIVATE. Измените SELFDESTRUCT, чтобы не удалять ключ хранилища, и используйте специальное значение в одноразовом номере учетной записи, чтобы указать на деактивацию.

Причина: То же, что и выше, с деревьями Веркле учетные записи будут организованы по-другому: свойства учетной записи (включая хранилище) будут иметь отдельные ключи, но будет невозможно пройти и найти все используемые ключи. Манипулирование кодами SELFDESTRUCT ранее требовало обширных изменений в состоянии учетной записи, что очень затрудняло дальнейшее использование SELFDESTRUCT в деревьях Verkle.

Изменять:

Измените правила, введенные EIP-2681, чтобы обычные приращения nonce ограничивались 2 ^ 64-2 вместо 2 ^ 64-1;

САМОРАЗРУШЕНИЕ изменено на:

Не удаляйте ключи хранилища и оставьте учетную запись на месте;

Перенесите баланс учетной записи на целевой и установите баланс учетной записи на 0.

Установите для одноразового номера учетной записи значение 2^64-1.

Нет возврата с EIP-3529;

Соответствующее правило SELFDESTRUCT для EIP-2929 остается без изменений.

значение:

Это предложение более гибкое, чем другие варианты поведения, которые напрямую удаляют SELFDESTRUCT.

EIP-6190 (устарело): изменить SELFDESTRUCT, совместимый с Verkle, чтобы он вызывал только ограниченное количество изменений состояния.

Причина: То же, что и выше, с деревьями Веркле учетные записи будут организованы по-другому: свойства учетной записи (включая хранилище) будут иметь отдельные ключи, но будет невозможно пройти и найти все используемые ключи. Манипулирование кодами SELFDESTRUCT ранее требовало обширных изменений в состоянии учетной записи, что очень затрудняло дальнейшее использование SELFDESTRUCT в деревьях Verkle.

Изменение: вместо уничтожения контракта в конце транзакции, в конце транзакции, вызвавшей его, происходит следующее:

Код контракта установлен на 0x1, а случайное число установлено на 2^64-1.

0-й слот контракта устанавливается на адрес, который будет опубликован, когда контракт использует код операции CREATE (keccak256(contractAddress, nonce)). Случайное число всегда 2^64-1.

Если контракт самоуничтожается после переадресации вызова одним или несколькими контрактами псевдонимов, установите 0-й слот хранения контракта псевдонимов на адрес, рассчитанный на шаге 2;

Весь баланс контракта будет переведен на адрес в верхней части стека;

Верхняя часть стека выталкивается.

значение:

Разработан, чтобы позволить SELFDESTRUCT впоследствии формировать деревья Веркле с минимальными изменениями;

Стоимость газа увеличилась с применением EIP-2929.

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

EIP1153X

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

причина:

Выполнение транзакции в Ethereum может генерировать несколько вложенных фреймов выполнения, каждый фрейм создается с помощью инструкции CALL (или аналогичной). Контракты могут быть повторно введены в одну и ту же транзакцию, и в этом случае более одного фрейма принадлежит одному контракту.

В настоящее время эти фреймворки могут взаимодействовать двумя способами: ввод/вывод через инструкции CALL и через обновления хранилища. Связь через ввод-вывод небезопасна, если существует промежуточная структура, принадлежащая другому ненадежному контракту.

Взяв в качестве примера reentrancylock, он не может полагаться на промежуточные кадры для передачи состояния блокировки: связь SSTORE SLOAD через хранилище стоит дорого, а временное хранилище — это выделенное и экономичное решение проблемы межкадровой связи.

Изменено: в EVM добавлены два новых кода операции: TLOAD (0xb3) и TSTORE (0xb4).

Временное хранилище является частным для контракта, которому оно принадлежит, и, как и в случае с постоянным хранилищем, только структура контракта, владеющая им, может получить доступ к его эфемерному хранилищу. При доступе к хранилищу все фреймы обращаются к одному и тому же эфемерному хранилищу так же, как и к постоянному хранилищу, но иначе, чем к памяти.

Возможные варианты использования:

повторный вход;

Вычисляемые адреса CREATE2 в цепочке: параметры конструктора считываются из фабричного контракта, а не передаются как часть хэша кода инициализации;

Утверждение EIP-20 для одной транзакции, например, #temporaryApprove(addressspender, сумма uint256);

Контракт на комиссию за перевод: платите комиссию за контракт на токен, чтобы разблокировать переводы во время транзакций;

Режим «Till»: позволяет пользователю выполнять все операции как часть обратного вызова и проверяет, сбалансировано ли «till» в конце;

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

значение:

Экономьте газ и используйте более простые правила выставления счетов за газ;

Решить проблему межкадровой связи;

не изменяет семантику существующих операций;

Нет необходимости очищать слот для хранения после использования;

Будущие проекты хранения (такие как деревья Веркле) не должны учитывать проблему возвратных платежей за мгновенное хранение.

Затем есть 4788, что может снизить доверие к залоговому пулу.

EIP4788: X

Кратко: блоки Beacon уходят корнями в EVM.

Обновление: на собрании разработчиков 15.06.23 разработчики предложили внести изменения в код, чтобы улучшить работу стейкеров, этот EIP раскроет корень блока цепочки маяка, который содержит информацию о состоянии внутренней цепочки EVM, для разработчиков DApp. сведен к минимуму доступ.

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

Значение: Это предложение по модификации кода, в котором предлагается модифицировать виртуальную машину Ethereum (EVM), чтобы она могла раскрывать данные корня состояния контрактного уровня (CL) на исполнительном уровне (EL), который может создавать различные протоколы и приложений в сети Ethereum Связь между программами стала более эффективной и безопасной. Разрешить более ненадежные проекты для пулов ставок, мостов и протоколов повторных ставок.

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

EIP5656X

Введение: MCOPY- инструкция копирования памяти.

ОБНОВЛЕНИЕ: 06.09.23 команда разработчиков заявила, что они изначально разделились по поводу MCOPY, потому что, хотя это решило проблему безопасности, они были обеспокоены пропускной способностью реализации + тестирования, необходимой для добавления его в обновление, но в конце концов согласились включить EIP. , Однако, если разработчик обнаружит проблемы с емкостью при тестировании или на стороне клиента, он будет рассмотрен для удаления. Таким образом, MCOPY временно включен в обновление Cancun.

Изменено: предоставлена эффективная инструкция EVM для копирования областей памяти.

Важность. Копирование памяти является фундаментальной операцией, но ее реализация на EVM требует затрат.

Наличие инструкции MCOPY позволяет более точно копировать кодовые слова и предложения, что повысит производительность копирования в память примерно на 10,5%, что очень полезно для различных вычислительно-емких операций;

Компиляторам также было бы полезно генерировать более эффективный и меньший байт-код;

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

Список кандидатов EIP

15 и 23 июня на консенсусном собрании разработчиков обсуждалось, какие EIP, ориентированные на CL, следует включить в Deneb, среди которых было предложено добавить EIP6988, EIP7044 и EIP7045.

EIP6988: X

Резюме: Предотвращает избрание валидаторов с косой чертой в качестве предлагающих блоки.

Значение: увеличение штрафов за нарушение узлов пойдет на пользу DVT.

EIP7044: X

Резюме: Обеспечение постоянной действительности подписанных выходов валидатора.

Значимость: это может в определенной степени улучшить опыт стейкера.

EIP7045: X

Резюме. Расширьте диапазон включения аттестационных слотов с скользящего окна в одну эпоху до двух эпох.

Значение: Повышение безопасности сети.

Удалить анализ EIP

На 160-м заседании Ethereum ACDE 29 и 23 апреля было подтверждено, что EVMMAX и EOF будут удалены из этого обновления, и изменения, связанные с EOF, могут быть внесены в последующие ежедневные обновления.

EVMMAXEIP：

Резюме: EVMMAX стремится повысить гибкость арифметических операций и схем подписи в Ethereum. В настоящее время существует два предложения EVMMAX: одно с EOF и одно без EOF.

EIP6601: Модульные арифметические расширения EVM (EVMMAX)

Изменение: это итерация EIP5843, отличие от EIP5843:

6601 вводит новый тип раздела EOF, в котором хранится модуль, предварительно вычисленный параметр Монтгомери, количество значений, которые будут использоваться (модуль, настраиваемый во время выполнения, по-прежнему поддерживается);

6601 использует отдельное пространство памяти для значений EVMMAX с новыми кодами операций загрузки/сохранения для перемещения значений между памятью EVM<->EVMMAX;

6601 поддерживает операции с модулями до 4096 бит (предварительный предел, указанный в EIP).

Значение: EIP-5843 вводит эффективное модульное сложение, вычитание и умножение для виртуальной машины Ethereum, а EIP-6601 основывается на этом, добавляя раздел настройки, отдельное пространство памяти и новые коды операций для модульных арифметических операций. Обеспечивает лучшую организацию и гибкость. при поддержке более крупных модулей и повышении производительности EVM.

В качестве контракта EVM, позволяющего выполнять арифметические операции с эллиптическими кривыми на различных кривых, включая BLS12-381;

MULMOD снижает стоимость газа при работе со значениями до 256 бит на 90-95% по сравнению с существующими кодами операций ADDMOD;

Позволяет реализовать предварительную компиляцию modexp в виде контрактов EVM;

Значительно снизить стоимость проверки ZKP в алгебраических хеш-функциях (таких как MiMC/Poseidon) и EVM.

ЭИП6690:

Изменение: EIP-6990 — это предложение, адаптированное из EIP-6601 для введения оптимизированных модульных арифметических операций в EVM без использования EOF. В то время как EIP-6601 требует EIP-4750 и EIP-3670 в качестве зависимостей, EIP-6990 предоставляет более автономное решение. Он обеспечивает более упрощенный подход, удаляя зависимость от EOF.

Значение: он сохраняет основные функции EIP-6601 для выполнения оптимизированных модульных арифметических операций над нечетными модулями до 4096 бит, это упрощение позволяет более эффективно внедрять и внедрять, сохраняя при этом преимущества, связанные с EIP-6601.

EOFchanges：

Введение: EOF - это обновление EVM, которое вводит новые стандарты контрактов и некоторые новые коды операций.Традиционный байт-код EVM (байт-код) представляет собой неструктурированную последовательность байт-кода инструкций. EOF представляет концепцию контейнера, который реализует структурированный байт-код. Контейнер состоит из заголовка и нескольких разделов для структурирования байт-кода. После обновления EVM сможет осуществлять контроль версий и одновременно запускать несколько наборов правил контрактов.

EIP663:

Краткое описание: Неограниченное количество инструкций SWAP и DUP

Значимость: Путем введения двух новых инструкций: SWAPN и DUPN, которые отличаются от SWAP и DUP увеличением глубины стека с 16 элементов до 256 элементов.

ЭИП3540:

Введение:

Раньше байт-код EVM, развернутый в цепочке, не имел предопределенной структуры, и код проверялся только перед запуском в клиенте, что не только косвенно влияет на стоимость, но и мешает разработчикам внедрять новые функции. , Или отказаться от старой функциональности.

Этот EIP вводит контейнер, который можно расширять и управлять версиями для EVM, и объявляет формат контракта EOF.На основе этого код может быть проверен при развертывании контракта EOF, то есть проверка во время создания, что означает, что это может предотвратить развертывание необоснованных контрактов, соответствующих формату EOF.Это изменение реализует контроль версий EOF, что поможет отключить существующие инструкции EVM или ввести крупномасштабные функции (например, абстракцию учетной записи) в будущем.

значение:

Контроль версий способствует внедрению или прекращению поддержки новых функций в будущем (например, введение абстракции учетной записи);

Разделение кода контракта и данных выгодно для проверки L2 (op), снижая стоимость газа для валидаторов L2.В то же время разделение кода контракта и данных также более удобно для инструментов анализа данных в цепочке.

ЭИП3670:

Введение: на основе EIP-3540 цель состоит в том, чтобы гарантировать, что код контракта EOF соответствует формату и действителен.Для контрактов, которые не соответствуют формату, его развертывание будет предотвращено, и Legacybytecode не будет затронут.

Значение: на основе контейнера, представленного 3540, EIP-3670 гарантирует, что код в контракте EOF действителен, или предотвращает его развертывание. Это означает, что неопределенные коды операций не могут быть развернуты в контрактах EOF, что дает дополнительное преимущество, заключающееся в уменьшении количества версий EOF, которые необходимо добавить.

ЭИП4200:

Введение:

Представлены первые специфичные для EOF коды операций: RJUMP, RJUMPI и RJUMPV, которые кодируют места назначения как непосредственные значения со знаком. Компиляторы могут использовать эти новые коды операций JUMP для оптимизации затрат газа на развертывание и выполнение JUMP, поскольку они устраняют время выполнения, необходимое для выполнения анализа перехода для существующих кодов операций JUMP и JUMPI. Этот EIP является дополнением к dynamicjump.

По сравнению с традиционной операцией JUMP разница в том, что такие операции, как RJUMP, не задают конкретное положение смещения, а задают относительное положение смещения (от динамических переходов -> статические переходы), потому что статических переходов часто бывает достаточно.

Значение: оптимизация сети и снижение затрат.

ЭИП4750:

Продвиньте функцию 4200 на один шаг вперед: путем введения двух новых кодов операций CALLF и RETF реализуется альтернативное решение для ситуации, которую нельзя заменить RJUMP, RJUMPI и RJUMPV, так что JUMPDEST больше не требуется в контракте EOF, то есть, поэтому динамический переход отключен.

Значение: оптимизировать код, разделив код на несколько частей.

ЭИП5450:

Предыстория: Предыстория по-прежнему заключается в том, что контракт Ethereum не проверяется при его развертывании, а при его запуске выполняется только серия проверок, не переполняется ли стек (верхний предел — 1024), достаточно ли газа и скоро.

Содержание: добавлена еще одна проверка валидности контрактов EOF, на этот раз вокруг стека. Этот EIP предотвращает ситуации, когда развертывание контракта EOF может привести к недозаполнению/переполнению стека. Таким образом, клиенты могут сократить количество проверок достоверности, которые они выполняют во время выполнения контрактов EOF.

Важность. Основное улучшение заключается в том, чтобы сделать эти проверки во время выполнения как можно меньше, а при развертывании контракта — больше проверок.

После обновления собрания разработчиков 26 мая изменение типа транзакции с SSZ на RLP, связанное с EIP4844, означало, что два SSZEIP в Канкуне больше не нужны, поэтому EIP6475 и 6493 были перемещены из Канкуна для обновления.

EIP6475X

Введение: Сопутствующее предложение для EIP4844. Proto-danksharding вводит новый тип транзакций, который использует кодировку SSZ вместо кодировки RLP, используемой другими типами транзакций.

ОБНОВЛЕНИЕ: во время 161-й встречи основных разработчиков Ethereum Execution Layer обсуждение формата сериализации SSZ для EIP4844 показало, что изначально разработчики склонны внедрять ранние итерации формата SSZ в EL посредством транзакций больших двоичных объектов, и в конечном итоге разработчики планируют внедрить все типы транзакций. был обновлен с RLP до SSZ, но разработчики обдумывали удаление SSZ из EIP-4844, учитывая его неясный путь и, конечно же, не имея возможности реализовать его при обновлении Cancun. После долгих обсуждений разработчики согласились удалить SSZ из EL-реализации EIP-4844, но еще не удалили EIP6475. После обновления от 26 мая изменение SSZ->RLP будет означать, что два SSZEIP в Канкуне больше не нужны: поэтому EIP 6475 и 6493 будут перемещены из Канкуна для обновлений.

EIP6493X

Введение: схема подписи транзакций SSZ. Этот EIP определяет схему подписи для транзакций, закодированных с помощью простой сериализации (SSZ), и определяет, как узлы должны обрабатывать типы транзакций больших двоичных объектов, которые отформатированы в формате SSZ на CL, но кодируются по-разному на EL. Этот EIP является частью обновления формата сериализации Ethereum для межуровневой согласованности;

Предыстория: изменения SSZ

Введение: SimpleSerialZe — это метод сериализации, используемый в цепочке маяков.

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

EIP6465: корень снятия SSZ, который определяет процесс миграции существующих обязательств Merkle-PatriciaTrie (MPT) на снятие средств с помощью простой сериализации (SSZ);

EIP6404/EIP6466:

Оба определяют процесс переноса существующих обязательств Merkle-PatriciaTrie (MPT) в простую сериализацию (SSZ).

EIP-6404 — корень транзакции SSZ

EIP-6466 — Приемная база ССЗ

Тим Бейко предложил на собрании основных разработчиков 26 мая, чтобы будущие разговоры о расширении сферы охвата Канкуна были ограничены следующими пятью EIP: EIP5920, 5656, 7069, 4788 и 2537, и что последующие предложения будут генерироваться в рамках этой области. Последующие EIP5656 и EIP4788 были подтверждены как формальные предложения по обновлению, а 5920, 7069 и 2537 были удалены.В том числе EIP5920 был вызван опасениями разработчиков по поводу возможных побочных эффектов способа передачи ETH, а также незавершенными рассуждениями, тестированием, и работа по обеспечению безопасности Удалено из обновления.

EIP5920: X

Введение: платежный опкод. Представляет новый код операции PAY для переводов Ethereum, который отправляет эфир на адрес без вызова каких-либо его функций.

Причина: в настоящее время для отправки эфира на адрес требуется, чтобы пользователь вызывал функцию по этому адресу, что имеет несколько проблем:

Во-первых, это открывает вектор для повторных атак, поскольку получатель может перезвонить отправителю;

Во-вторых, он открывает DoS-вектор, поэтому родительская функция должна знать, что у получателя может закончиться газ или обратный вызов;

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

Изменять:

Введен новый опкод: (PAY)PAY_OPCODE, где:

Вытолкнуть из стека два значения: addrthenval.

Перенести wei с адреса выполнения val на адрес addr. Если адрес нулевой, valwei будет запрограммирован с адреса выполнения.

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

Значение: экономия газа.

ОБНОВЛЕНИЕ: 06.09.23 PAY был удален из обновления из-за опасений по поводу потенциальных побочных эффектов, которые могут возникнуть при передаче ETH, а также из-за обоснования, тестирования и работы по обеспечению безопасности, необходимых для принятия предложения.

EIP7069X

Введение: Модифицированная инструкция CALL

Изменение: введены три новые инструкции вызова, CALL2, DELEGATECALL2 и STATICCALL2, которые упрощают семантику. Направлена на то, чтобы убрать наблюдаемость газа из новой директивы и открыть дверь для нового класса контрактов, на которые не влияет переоценка.

фон:

Правило 63/64: ограничить глубину вызова и убедиться, что у вызывающей стороны есть оставшийся газ для внесения изменений в состояние после возврата вызываемой стороны;

До того, как были введены правила 63/64, доступный газ вызывающему абоненту необходимо было рассчитать достаточно точно. В Solidity есть сложное правило, которое пытается оценить стоимость выполнения самого вызова на стороне вызывающей стороны, чтобы установить разумное значение газа.

В настоящее время введено правило 63/64:

Удалена проверка глубины вызова;

Перед выполнением вызываемого поведения обязательно зарезервируйте не менее 5000 газа;

Убедитесь, что для вызываемого поведения доступно не менее 2300 газа.

Правила субсидий: такие как известная субсидия 2300, когда контракт вызывает другой контракт, вызванный контракт получает 2300gas для выполнения очень ограниченных операций (достаточно, чтобы сделать небольшой расчет и создать журнал, но недостаточно, чтобы заполнить слот хранения ), поскольку он устанавливает фиксированное количество газа, пока цена на газ может быть скорректирована, люди не могут определить, какой тип расчета может поддерживать этот газ.

Значение: подготовить почву для внедрения EOF в будущем и упростить выполнение крупных контрактов.

Удалить опциональность газа: новая команда не позволяет указать лимит газа, но опирается на «правило 63/64» (в основном ссылаясь на переоценку газа, используемую для большого количества операций ввода-вывода в EIP-150, что увеличивает потребление газа для конкретных операций) до Ограничение газа, это важное улучшение заключается в упрощении правил вокруг «субсидии», независимо от того, отправляется ли значение или нет, вызывающему абоненту не нужно выполнять расчеты по газу;

С введением нового предложения пользователи всегда могут преодолеть ошибку Outof Gas, отправив больше газа в транзакции (конечно, с учетом лимита газа в блоке).

Некоторые контракты, которые отправляли только ограниченное количество газа на свои вызовы, были нарушены новым механизмом расчета стоимости, когда ранее повышались затраты на хранение (например, EIP-1884 увеличил газ для определенных кодов операций). Ранее в некоторых контрактах была газовая шапка, которая постоянно ограничивала количество газа, которое они могли потратить, даже если они отправляли его в свои дополнительные вызовы, это не срабатывало, независимо от того, сколько дополнительного газа они отправляли, потому что вызов ограничивал бы сумма отправлена.

Проложите путь к внедрению EOF: как только будет введен объектный формат EVM (EOF), старые инструкции по вызову могут быть отклонены в контракте EOF, гарантируя, что они в значительной степени невосприимчивы к изменениям цен на газ. Поскольку эти операции необходимы для устранения наблюдаемости газа, EOF потребует их вместо существующих инструкций;

Дополнительные коды возврата состояния удобства: введены удобные функции, которые возвращают более подробные коды состояния: успех (0), возврат (1), сбой (2) и могут быть расширены в будущем.

EIP2537: X

Кратко: предварительная компиляция обработки кривой BLS12-381.

ИЗМЕНЕНО: добавлены операции с кривой BLS12-381 в качестве прекомпиляции набора, необходимого для эффективного выполнения таких операций, как проверка подписи BLS и выполнение проверки SNARK.

Значение: Ethereum может создавать более безопасные криптографические доказательства и обеспечивать лучшую совместимость с цепочкой маяков.

PR3175 упоминался, но не попал в шорт-лист, без дальнейшего обсуждения

PR3175：X

Резюме: это предложение не позволит оштрафованным валидаторам предлагать блоки при исключении из очереди. Если более 50% валидаторов будут оштрафованы за злонамеренное поведение, эти валидаторы по-прежнему смогут предлагать блоки при принудительном удалении из сети. Изменение этой логики является относительно небольшим изменением уровня CL, которое обеспечивает защиту от «режимов с высоким уровнем отказов», говорят разработчики.

Согласно 108-му совещанию разработчиков Ethereum Core, состоявшемуся 4 мая, PR3175 находится в процессе форматирования как EIP и будет изменен на EIP-6987, то есть по соображениям безопасности, чтобы предотвратить выбор узлов проверки с косой чертой. предлагающий блок.

будущее

На основании вышеизложенной информации мы пришли к следующим выводам:

1. Основными целями модернизации Канкун являются, в порядке приоритета, расширение, безопасность, экономия газа и функциональная совместимость:

Нет сомнения, что расширение является первоочередной задачей (4844);

Безопасность и экономия газа на втором месте (6780, 1153, 5656 и 7045), при этом учитывается определенный опыт разработчиков;

В-третьих, это совместимость, например, оптимизация соединения, связи и взаимодействия между децентрализованными приложениями (4788, 7044 и 6988);

Ожидаемые данные: Testnet 4844 может снизить стоимость opsiderollup на 50%; технические решения EigenLayer и Celestia не слишком много раскрыли, и их данные невозможно оценить; Ethstorage оценивает, что стоимость DA снизится до 5% от исходной Ожидается, что Topia снизит стоимость в 100~1000 раз.

2. Следующие 2–5 лет, когда Канкун будет переведен на Danksharding, станут золотым периодом разработки для проектов уровня DA.

Верхний предел безопасности уровня 2 зависит от используемого уровня DA. Proto-Danksharding принесет пользу протоколам хранения, модульным протоколам и сетям расширения хранения L1 за счет более дешевого хранилища данных о состоянии.

Во-первых, Danksharding возвращается к сути конечного автомата Ethereum. V God упомянул, что цель консенсусного протокола Ethereum не в том, чтобы гарантировать постоянное хранение всех исторических данных. Вместо этого цель состоит в том, чтобы предоставить высоконадежную доску объявлений в реальном времени и оставить место для других децентрализованных протоколов для более длительного хранения (цель протокола консенсуса Ethereum не в том, чтобы гарантировать вечное хранение всех исторических данных. Скорее, цель заключается в обеспечении высокозащищенной доски объявлений в режиме реального времени и оставлении места для других децентрализованных протоколов для долгосрочного хранения данных.);

Во-вторых, Danksharding снижает стоимость DA, но также необходимо решить проблемы фактического времени посадки и доступности данных.

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

Фактическое время посадки велико, а TPS, которое можно улучшить, и газ, который можно уменьшить, по-прежнему ограничены, поэтому это хорошо для дальнейшего развития проектов слоев DA в будущем:

В статье полыни iablesecurity о сегментировании данных о данкшардинге показано, что для внедрения потребуется 2-5 лет;

Даже если он приземлится, TPS, который он может увеличить, и уровень газа, который он может снизить, все еще ограничены:

EIP4844 в настоящее время поддерживает 6 больших двоичных объектов, и проблема будущего расширения может быть решена только с помощью Danksharding;

Текущее пространство блока Ethereum составляет около 200 КБ. После Danksharding запланированный размер в спецификации составляет 32 мегабайта, что примерно в 100 раз больше. В настоящее время TPS Ethereum составляет около 15, а в идеализированном состоянии будет около 1500 после увеличения в 100 раз, что не является большим улучшением по величине.

Таким образом, длительное время реализации + ограниченные фактические изменения принесут пользу проектам уровня DA.Некоторые проекты DA, такие как Celestia и Eigenda, все еще могут конкурировать с Danksharding за счет более дешевых затрат и более быстрого TPS.Новые проекты DA, такие как ETHstoragetopia, также могут заполнить предыдущий пробел на рынке.

Технические вопросы, такие как проблемы с хранением и доступностью данных, также должны быть решены:

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

Блоб будет храниться на уровне консенсуса Ethereum в течение примерно 3 недель, а затем удален.Если вы хотите хранить полные исторические записи и сделать все данные доступными, текущие решения включают в себя: само dapp хранит данные, связанные с ним, и сеть портала Ethereum. (в настоящее время в разработке) в разработке) или сторонние протоколы, такие как обозреватели блоков, исторические данные в BitTorrent или спонтанное хранение отдельными пользователями.

Таким образом, Proto-Danksharding принесет пользу протоколам хранения, модульным протоколам и сетям расширения хранения L1:

Спрос на вызов исторических данных приведет к новому каналу разработки для протоколов децентрализованного хранения или сторонних протоколов индексирования;

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

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

3. Обновление Cancun хорошо для разнообразия L2, L3, RAAS и доступности данных и других направлений

Анализ дорожки L2:

Верхний уровень 2, пять проектов, таких как ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (в рамках StarkWare) и HyperChain (в рамках zkSync), выиграют. Снижение платы за хранение, вызванное большим двоичным объектом, значительно улучшит предыдущую серию проблем стоимости и масштабируемости, которые ограничивали разработку уровня 2, и значительно повысит пропускную способность данных.После решения проблемы стоимости головной уровень 2 будет иметь возможность продолжить развертывание конкретных функции высокого уровня Индивидуальная многоцепочечная параллельная экология L3;

Разрыв в операционных расходах между второстепенным Layer 2 и основным Layer 2 будет сокращен, что даст больше возможностей для развития некоторым небольшим проектам, таким как Aztec, Metis, Boba, ZKspace, layer2.finance и т. д.;

Хотя реальные потребности модульных блокчейн-проектов еще предстоит проверить, по-прежнему возможны различные языки программирования, такие как Cario от Starkware, языки серии Move, поддерживаемые Wasm языки серии C, C++, C# и Go, которые могут представить больше многих web2 Разработчики.

Анализ трека Рааса:

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

Но проблема с дорожкой RAAS в том, что это может быть OverHype, и есть даже сомнения по поводу самой дорожки RAAS. Столкнувшись с конкуренцией со стороны 5 лучших слоев layer2 и появлением различных новых DA, мы должны поставить вопросительный знак в отношении того, могут ли новые проекты формировать трек.

Прежде всего, преимущество развертывания цепочки приложений головного уровня 2 заключается в целостности сетевого каркаса и безопасности межцепочечной экологии, а преимущество RAAS — в его кастомизации и свободе;

Тем не менее, технические барьеры RAAS серий OP и ZK в настоящее время не сильны, и в краткосрочной перспективе они все еще находятся на стадии тестовой сети, и фактического взаимодействия продуктов нет.Учитывая фактический прогресс RAAS, технических форм и экологические преимущества layer3 в будущем, реальный спрос на RAAS сомнительный.

Серия OP: несмотря на то, что базовое обновление +4844 стека OP принесло некоторые небольшие улучшения в стоимости и эффективности, привлекательность улучшений невелика;

Серия ZK: В настоящее время многие ведущие проекты следуют маршруту ZKEVM и уделяют больше внимания совместимости с Ethereum, поэтому дизайн схемы принесет в жертву определенную эффективность, и он не так целенаправлен, как серия OP. Тем не менее, большинство ZKRAAS, представленных в настоящее время на рынке, по-прежнему используют ведущие проекты (такие как ZkSync) для разветвления цепочки, и барьеры все еще не сильны.

Таким образом, в краткосрочной перспективе у OPRAAS еще есть возможности для развития, прежде чем появится Layer 3. В долгосрочной перспективе ZKRAAS и Layer 3 могут стать будущей тенденцией.

ZKRAAS имеет больший недостаток в стоимости после 4844, и он потребляет гораздо больше вычислительной мощности, чем OP.Хотя стоимость загрузки на L1 меньше, чем у OP, это всего лишь капля в море по сравнению со стоимостью процесса доказательства, в то время как OP Преимущество в том, что он может быстро построить экологию за короткий промежуток времени, и еще есть место для развития до того, как приземлится слой 3;

Для обычных приложений DeFi и рынков NFT трансформация агрегации не является жестким требованием: только платежные приложения или игры, требующие высокой эффективности, имеют более высокий спрос на агрегацию. В будущем проекты defi могут быть на уровне 2, социальные проекты могут быть на уровне 3 или вне сети, и, наконец, основные данные и отношения будут размещены на уровне 2. Игровые проекты должны перейти на уровень 3 или объединиться, но, учитывая, что большая часть текущих цепные игры — это, по сути, фонды, и невозможность внешней циркуляции токенов привела к узким местам в разработке, в сочетании с появлением игр во всей цепочке, экологическая привлекательность самого l3 намного выше, чем у накопительного.

4. Обновление Cancun улучшает опыт разработчиков и пользователей

Второе важное предложение обновления Cancun, SELFDESTRUCTremoval, еще больше улучшит безопасность Ethereum.В то же время для проблемы процедурного обновления учетной записи, которая может существовать после удаления, подготовлен новый код операции SETCODE для улучшения этой ситуации;

Третье предложение EIP1153, обновленное Cancun, добавляет временные коды операций хранилища, которые могут, во-первых, экономить газ, во-вторых, решать проблему межкадровой связи и, наконец, прокладывать путь для будущего дизайна хранилища, такого как дерево Веркле не нужно будет рассматривать возмещение вопрос временного хранения;

EIP5656, четвертое предложение обновления Cancun, представляет инструкцию копирования памяти MCOPY, которая может более точно копировать кодовые слова и предложения, что улучшит производительность копирования памяти примерно на 10%;

Пятым предложением обновления Cancun является EIP4788, который может сделать связь между различными протоколами и приложениями в сети Ethereum более эффективной и безопасной, а также позволить более ненадежные конструкции для пулов ставок, протоколов мостов и повторных ставок;

Последнее обновление Cancun (15, 23 июня) предлагает добавить обновления EIP, ориентированные на CL: EIP6988, EIP7044 и EIP7045, которые улучшают безопасность и удобство использования Ethereum в деталях, таких как улучшение опыта залогодателя и повышение безопасности сети и т. д.

Среди удаленных предложений переход SSZ->RLP привел к удалению двух SSZEIP (EIP6475 и EIP6493) из обновления Cancun; предложения, связанные с EOF, были снова удалены из обновления Cancun после удаления из обновления Shanghai и в настоящее время рассматриваются. возможно Это будет напрямую реализовано в более поздних ежедневных обновлениях; EVMMAX также удален из Канкуна для обновлений вместе с EOF, потому что это подмножество EIP, связанное с внедрением EOF; учитывая потенциальные побочные эффекты, которые могут существовать на пути передачи ETH, и необходимость передать предложение Рассуждение, тестирование и работа по обеспечению безопасности, EIP5920 удален из обновления.

5. Связь с zkml и абстракцией аккаунта

Незначительное влияние на zkml

ZKML представляет собой комбинацию доказательства с нулевым разглашением (ZeroKnowledge) и машинного обучения (Machine Learning); комбинация блокчейна и модели ML решает проблемы защиты конфиденциальности и проверяемости машинного обучения:

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

Проверяемость: технология доказательства с нулевым разглашением имеет широкий спектр применений, а ZKP позволяет пользователям знать правильность информации без проверки. А поскольку модель машинного обучения требует большого количества вычислений, модель машинного обучения может генерировать доказательства с помощью ZK-SNARK, уменьшая размер доказательства и уменьшая потребность в вычислительной мощности машинного обучения.

Требования к хранилищу ZKML имеют мало общего с DA: требуется отдельная структура хранения, такая как пространство и время, а его основной технологией является новый протокол безопасности «SQL Proof». Формат SQL и загрузка результатов непосредственно в смарт-контракты;

ZK-SNARKs — это основная форма ZK в ZKML, которая может адаптироваться к требованиям вычислительной мощности ML в цепочке.С развитием криптографии особенно рекурсивные доказательства SNARK принесут пользу реализации ZKML в цепочке:

ZK-SNARKs характеризуются высокой компактностью.Использование ZK-SNARKs позволяет доказывающему сгенерировать короткое доказательство, при этом верификатору не нужно взаимодействовать и нужно выполнить лишь небольшой объем вычислений для проверки его достоверности.Для этого требуется только один доказывающий Природа взаимодействия с верификаторами делает ZK-SNARK эффективными и практичными в практических приложениях и больше подходит для требований к вычислительной мощности ML в цепочке.

В настоящее время обучение в цепочке невозможно, и в цепочке могут храниться только результаты вычислений вне цепочки:

Текущая проблема ML больше связана с неудовлетворенными требованиями к вычислительной мощности и низкой производительностью, вызванной ограничениями алгоритма (нельзя рассчитывать параллельно).Большая модель ZK доказывает, что требуется более высокая вычислительная мощность, которую нельзя поддерживать в цепочке. популярные ZK-SNARK поддерживают только небольшое доказательство масштаба ML с нулевым разглашением и небольшой объем вычислений, то есть ограничение вычислительной мощности является ключевым фактором, влияющим на разработку приложений блокчейна ZKML, и цепочка может хранить только результаты расчеты вне сети.

Хорошая абстракция аккаунта

Прежде всего, обновление Cancun может в определенной степени снизить стоимость доказательства ZKrollup:

Текущая комиссия за транзакцию zkSync зависит от 3 аспектов:

Фиксированная стоимость ресурсов, потребляемых верификатором для создания сертификата SNARK и его проверки, относительно высока;

Плата за газ, когда верификатор отправляет доказательство SNARK в основную сеть Ethereum, эта часть платы будет соответственно увеличиваться из-за перегрузки основной сети;

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

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

Во-вторых, абстракция учетной записи преобразует традиционные транзакции tx в пользовательские операции, а затем упаковывает пользовательские операции в блоки с помощью ECDSA, который занимает больше места в цепочке, чем раньше, поэтому требования к хранилищу выше;

Тогда абстракция аккаунта и ZKrollup могут дополнять друг друга:

В настоящее время проблема абстракции учетной записи заключается в том, что GasFee дорог.Поскольку слишком много шагов и задействованы смарт-контракты, существует много данных, что делает GasFee дорогим.Преимущество ZKRollup заключается в том, что он может уменьшить объем данных;

Абстракция учетной записи затрудняет обеспечение безопасности: поскольку AA включает в себя несколько контрактов, безопасность является проблемой.Однако после постепенного формирования L2 в будущем уровень консенсуса больше не будет изменяться, смарт-контракты будут иметь больше применений, а безопасность абстракция учетной записи также увеличится.Это может быть гарантировано, а с доверенной проверкой ZKrollup безопасность будет еще больше улучшена.

Наконец, учитывая развитие технологии ИИ, она может помочь повысить безопасность внутрисетевых контрактов и оптимизировать внутрисетевые транзакции или этапы деятельности:

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

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

Таким образом, обновление Cancun постепенно принесет пользу будущему развитию абстракции учетной записи от расширения пространства для хранения до дополнения ZKrollup, а затем и до комбинации с технологией AI.

6. Оглядываясь назад на дорожную карту Ethereum, что дальше

В настоящее время Layer2 не имеет производительности, подобной Solana (с точки зрения задержки и пропускной способности), а также производительности фрагментации, такой как Near, и производительности параллельного выполнения, такой как Sui и Aptos.Обновление Cancun улучшило лидерство Ethereum в качестве лидер;

Предполагается, что после обновления в Канкуне несколько основных периодов разработки будут полностью посвящены данкшардингу (2–5 лет), посадке MEV и PBS (1–3 года), абстракции учетной записи (1–2 года), ZK всему (3–3 года). 6 лет)), EOF и опыт разработки (сколько раз вы видели расширение?).

Бич

Цель: сосредоточиться на решении проблем с MEV.

Решение: сведите к минимуму MEV на прикладном уровне с помощью «разделения предложений и разработчиков» (PBS). В настоящее время можно оптимизировать большие двоичные объекты и ввести службы предварительного подтверждения или защиту от упреждения.

PBS — это разделение создателей блоков и сортировщиков. Сортировщик отвечает только за сортировку вне зависимости от цепочки, а создатель блока не заботится о транзакции, а напрямую выбирает пакет, сделанный сортировщиком, и помещает его в цепочку. Этот процесс сделает весь процесс более справедливым и облегчит проблему MEV, которая заключается в идее экстернализации MEV.

Степень завершенности PBS в настоящее время еще очень низкая, и более зрелым является сотрудничество с внешними решениями MEV — mevboost flashbots.

Расширенная версия «Enshrined Proposer-Builder Separation (ePBS)» имеет более низкую степень завершенности и более длительный цикл, и предполагается, что она не будет реализована в краткосрочной перспективе. Кроме того, существуют прогрессивные версии PEPC и Оптимистическая ретрансляция, повышающая гибкость и адаптивность платформы PBS.

Грань

Цель: использовать дерево Verkel для замены Merkle, внедрить решение для минимизации доверия, позволить легким узлам получить такую же безопасность, как и полные узлы, и сделать проверку блоков максимально простой и переносимой.

В то же время ZKизация L1 явно добавлена в дорожную карту Verge, ZK станет общей тенденцией будущего расширения и ускорения;

Решение: внедрить zk-SNARK для замены старой системы подтверждения, включая облегченные клиенты на основе SNARK, SNARK с изменениями состояния консенсуса, EnshrinedRollups.

Деревья Веркла являются более эффективной альтернативой деревьям Меркла для конкретных состояний, которым не нужно предоставлять путь от каждого сестринского узла (узлов, имеющих одного и того же родителя) к выбранному узлу, а только сам путь в качестве доказательства. Частично доказательства Веркла в 3 раза эффективнее, чем доказательства Меркла.

EnshrinedRollup относится к Rollup, который имеет какую-то согласованную интеграцию на L1. Преимущество состоит в том, что он наследует консенсус L1 и не требует токенов управления для выполнения обновлений rollup. В то же время, выполняя вычисления вне цепочки и публикуя только результаты в блокчейн, это может увеличить количество транзакций, но техническая сложность реализации относительно велика. Комбинация этих объединений в будущем сможет удовлетворить большинство потребностей экосистемы блокчейна в ближайшие несколько десятилетий.

Чистка

ThePurge относится к цели упрощения протокола за счет снижения требований к хранилищу для участия в проверке сети. В первую очередь это достигается за счет гибернации и управления историей и состоянием. Бездействие исторических данных (EIP-4444) позволяет клиентам удалять исторические данные старше одного года и прекращать предоставление услуг на уровне P2P.

состояние покоя. Когда дело доходит до обработки роста состояния, есть две основные цели: слабое безгражданство, которое относится к цели использования состояния только для создания блоков, но не для его проверки; состояние, к которому осуществляется доступ. Режим гибернации должен уменьшить количество хранимых узлов состояния в общей сложности на 20–50 ГБ.

На пятом этапе Purge EIP4444 явно прописан в Roadmap.EIP-4444 требует от клиента очистить данные старше одного года.В то же время на этом этапе есть некоторые задачи по оптимизации EVM, такие как упрощение механизма Прекомпиляция GAS и EVM и др.;

Разорение

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