Прошлая жизнь

**Почему необходимо обновление Cancun? **

• Видение Ethereum состоит в том, чтобы стать более масштабируемым и безопасным в условиях децентрализации. Текущее обновление Ethereum также направлено на решение этой трилеммы, но столкнулось с большими трудностями.
• Проблемы с Эфириумом:
• В настоящее время TPS и производительность низкие, плата за газ высокая, а перегрузка серьезная.В то же время дисковое пространство, необходимое для запуска клиента Ethereum, также быстро растет.Внизу работа по обеспечению безопасность и децентрализация Ethereum Влияние алгоритма объемного консенсуса на всю среду также становится все более значительным.
• Таким образом, в условиях децентрализации, как передавать больше данных и уменьшить газ для повышения масштабируемости, и как оптимизировать алгоритм консенсуса для обеспечения безопасности — это все усилия, которые Ethereum в настоящее время прилагает.
• Чтобы решить трилемму безопасности, децентрализации и масштабируемости, Ethereum использовал механизм PoW-to-PoS для дальнейшего снижения порога узла, а также планирует использовать цепочку маяков для случайного назначения верификаторов для оптимизации безопасности. масштабируемости Ethereum рассматривает возможность использования сегментирования для снижения нагрузки на узлы, что также позволяет Ethereum создавать несколько блоков одновременно и повышать масштабируемость.
• Текущее пространство каждого блока Ethereum составляет около 200~300 КБ, минимальный размер каждой транзакции около 100 байт, около 2000 транзакций, разделенных на время блока 12 секунд, верхний предел TPS Ethereum ограничен примерно 100. Эти данные явно не могут удовлетворить потребности Ethereum.
• Поэтому Ethereum Layer 2 фокусируется на том, как поместить большой объем данных в блок В космосе безопасность гарантируется за счет доказательств мошенничества и доказательств достоверности, поэтому уровень DA определяет верхний предел безопасности, что также является основным содержанием обновления Cancun.
• Итеративный маршрут экологии Ethereum не может обеспечить производительность эталонного теста Solana (с точки зрения задержки и пропускной способности), а производительность фрагментации Near не будет замечена в краткосрочной перспективе, равно как и производительность параллельного выполнения Sui и Aptos. В краткосрочной перспективе Ethereum может построить только многоуровневую структуру с Rollup в качестве ядра, поэтому Cancun модернизируется, чтобы решить TPS, газ. Сборы и опыт разработчиков имеют решающее значение для дорожной карты Ethereum.

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

Последние несколько важных обновлений и их цели

• 2020год12месяц1* Сеть Beacon официально выпущена, что открывает путь к обновлению **POS ** *
• 2021**8месяц5** Лондонское обновление, EIP1559 изменяет экономическую модель Ethereum;
• 2022год9месяц15* Парижское обновление (** Слияние**), выполнено POW переключение POS;*
• 2023год4месяц12* Модернизация в Шанхае, решена проблема снятия залога;*
• Экономическая модель и обновления, связанные с POS, были завершены, и следующие несколько обновлений решили проблемы производительности Ethereum, TPS и опыта разработчиков;
• Следующий шаг — сосредоточиться на дорожной карте Ethereum The Всплеск .
• Цель: Достигните 100 000+ TPS в Rollup.
• Существует 2 схемы, ончейн и офчейн:
• Решение вне сети: относится к Layer2, включая объединение и т. д.
• Схема в цепочке: относится к внесению изменений непосредственно в L1, что является популярной схемой шардинга.Простое понимание шардинга состоит в том, чтобы разделить все узлы на разные области и выполнить задачи каждой области, что эффективно увеличит скорость;
• Анализ схемы шардинга:
• Дилемма схемы сегментирования: ранее сегментирование включало сегментирование состояния, сегментирование транзакций и т. д., но проблема синхронизации между различными сегментами. В настоящее время сложно выполнить крупномасштабную синхронизацию данных сетевого узла. , не только не может решить ситуацию с MEV, но также может потребовать большого количества патчей для устранения различных проблем, которые могут возникнуть, что не может быть реализовано в краткосрочной перспективе.
• Danksharding — это новый дизайн шардинга, предложенный для Ethereum, Его основной идеей является Централизованное производство блоков + Децентрализованная проверка + **Сопротивление цензуре,**Это также связано с доступностью данных, упомянутых ниже Выборка (DAS), Разделение производителей и упаковщиков блоков (PBS) и список устойчивости к цензуре (Crlist). Наибольшее значение основной идеи Danksharding заключается в превращении Ethereum L1 в единое поселение (расчет) и доступность данных (Доступность данных) Наличие）层。

*Схема шардинга разделена на 2 шагов, в настоящее время она разделена на **прото- шардинг и полный накопитель. ***

• Поэтому- Данкшардинг**：**
• представлять: Помогите снизить комиссию L2 и увеличить пропускную способность, введя большие двоичные объекты. , в то же время как решение для предварительного сегментирования, чтобы проложить путь к полному сегментированию. Ожидается, что после прото-данкшардинга реализация данкшаринга займет 2-5 лет.
• Содержание: основной особенностью прото-данкшардинга является введение нового типа транзакций больших двоичных объектов. Большие двоичные объекты обладают характеристиками большой емкости и низкой стоимости. Добавление таких пакетов данных в Ethereum может позволить хранить все сводные данные в больших двоичных объектах, что значительно снижает нагрузку на основную цепочку. Давление на хранилище также может снизить стоимость объединения.
• Полный накопитель
• Введение: накопительный пакет полностью расширен и ориентирован на использование доступных данных.
• содержание:
• P2P-дизайн DAS: некоторые работы и исследования, связанные с проблемами подключения к сети с разделением данных;
• Клиент выборки доступности данных: разработка облегченного клиента, который может быстро определить, доступны ли данные, путем случайной выборки нескольких килобайт;
• Эффективное самовосстановление DA: способность эффективно восстанавливать все данные в самых неблагоприятных условиях сети (например, при атаке злонамеренного валидатора или длительном простое узлов с большими блоками).

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

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

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

• Основной процесс: процесс обновления, ориентированный на EIP, примерно выглядит следующим образом: сначала EIP первоначально принимается на основной конференции разработчиков (сокращенно ACD), а затем команда клиента тестирует его независимо от того, включен ли EIP в обновления или нет, а также после окончательного тестирования просмотрите его еще раз, а затем решите, включать ли его в фактическое обновление на основе обсуждения.
• Конференции разделены на категории 2, которые представляют собой собрание уровня консенсуса и собрание исполнительного уровня, которые проводятся попеременно раз в две недели:
• ** Встреча на уровне консенсуса (Все Core Developers Consensus — ACDC), с упором на уровень консенсуса Ethereum (доказательство доли, цепочка маяков и т. д.);**
• Совещание на исполнительном уровне ( Все Решение Core Developers — ACDE**), ориентированное на исполнительный уровень Ethereum (EVM, **Gas расписание и т. д.).
• Существует 3 типа основных сопровождающих Ethereum, в основном это официальные организации или форумы волонтеров, на которых обсуждаются предложения:
• AllCoreDevs: сопровождающие кода, отвечающие за сетевой клиент ETH1, обновление, поддержку кода Ethereum и базовой архитектуры;
• Раздел «Управление проектами»: поддержка разработчиков Ethereum, координация хард-форков, мониторинг EIP и т. д., а также прямая помощь AllCoreDevs в общении и операциях;
• Эфириум Magicians: «Форум», на котором можно обсудить EIP и другие технические темы.

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

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

Этап 1 – Знакомство с темами обновления

Ввести новые задачипрото-данкшардинг***,EOF* и «самоуничтожение» * Код операции, поверхностное обсуждение содержания обновлений в Шанхае**

• После того, как слияние Ethereum было завершено 15, 22 сентября, собрание разработчиков было приостановлено на 4 недели, что позволило разработчикам проверить EIP, обсуждаемый в последующем обновлении, в течение одного месяца;
• 28 и 22 октября на первой встрече разработчиков после слияния впервые была предложена реализация прото-данкшардинга, EOF и опкода «самоуничтожение». и некоторые разработчики являются предварительными. На мой взгляд, шанхайское обновление можно разделить на несколько небольших обновлений, например, сначала включить обещанный вывод ETH, а затем обновить EIP. 4844, но другая группа разработчиков считает более целесообразным реализовать более крупное обновление за один шаг.

Этап 2 - Определение временных рамок и подготовка к церемонии KZG

В конце 2022** конференция Ethereum в основном вращается вокруг ***EOF и EIP. 4844 Обсуждение, продолжая продвигать EIP 4844 Церемония предварительной настройки, необходимая для церемонии ***—KZG, разработчики будут *******23 **** Год **** 1 **** месяц официально подтверждено, какое обновление **** 4844 **** появится в ***

• 22 ноября EOF или прото-данкшардинг упоминался на телефонной конференции всех основных разработчиков Эфириума № 149. В настоящее время разработчики все еще рассматривают возможность включения его в шанхайское обновление;
• На собрании уровня консенсуса 2 декабря 22 года Трент, глава экосистемы Ethereum Ван Эппс обновил EIP 4844: Прогресс в реализации требуемой доверенной церемонии установки для создания Код безопасности, используемый в 4844. Ван Эппс надеется, что церемония станет одной из крупнейших в криптопространстве, собрав от 8 000 до 10 000 взносов.Период публичного взноса на церемонию продлится около 2 месяцев и начнется где-то в декабре;
• На собрании основных разработчиков в тот же день обсуждались EOF и деактивация опкода самоуничтожения.Разработчик из Ethereum Foundation возражал против переноса EOF в Канкун, утверждая, что если изменения кода не будут включены в Шанхай, это Будет ли возможность входа в Канкун очень мала, что касается кода самоуничтожения, в то время есть разработчики, которые выступают за продвижение EIP. 4758, но отключение этого опкода напрямую приведет к поломке некоторых приложений, и разработчик считает, что этот EIP следует еще раз взвесить на некоторое время, прежде чем создавать крайний случай для защиты этого типа контракта;
• На собрании основных разработчиков 9 22 декабря было предложено провести церемонию KZG в отношении обновления в Канкуне и текущего EIP. 4844: Требуемая доверенная церемония установки готова;
• На собрании слоя консенсуса 16, 22 декабря по поводу EIP 4844, разработчики обсудили объединение двух разных запросов на извлечение (PR) в спецификацию для proto-danksharding, один из которых связан с тем, как узлы обрабатывают доступность данных после определенного момента после сокращения данных, а другой — когда для оповещения будут введены новые коды ошибок блока. узлы, когда информация о больших двоичных объектах отсутствует на
• Во время основной встречи разработчиков 05.01.23 разработчики достигли консенсуса по удалению модификаций кода, связанных с реализацией EOF, из Шанхайского обновления, в настоящее время Beiko предложила решить через две недели, следует ли включать EOF в Канкун. модернизированный;

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

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

• На основной встрече разработчиков 20 и 23 января EOF был перенесен в Канкун для обновления;
• На основной встрече разработчиков 6 23 марта предварительное предложение по обновлению в Канкуне было следующим: EIP. 4788 (общедоступный корень цепи маяков), EIP 2537 (эффективно выполнять такие операции, как проверка подписи BLS и проверка SNARK), EIP-5920 (вводит новый код операции PAY) и EIP. Комбинированная реализация 6189 (для обеспечения совместимости SELFDESTRUCT с деревьями Веркле) и EIP-6190 (изменение функции SELFDESTRUCT, чтобы вызвать только ограниченное количество изменений состояния);
• На основной встрече разработчиков 16 и 23 марта, за исключением EOF и EIP. 4844 были рассмотрены следующие предложения для включения в Канкун: формат SSZ, удаление SELFDESTRUCT, EIP 2537, EVMMAX, EIP

1153. Неограниченное количество инструкций SWAP и DUP, введение кодов PAY и корней состояния маяка в EVM;

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

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

В 234месяце есть четкое направление для предложений, которые должны быть охвачены обновлением Канкуна, и ключевые узлы находятся в 4 ************************************************* ******************************************************* ************ EIP и ****tim также провели более подробное обсуждение альтернативных предложений в 4месяц На заседании 27,*EIP 6780、ЭИП 6475 и EIP 1153 определяется как включенный в Канкун, и в то же время **EOF и EVMMAX (с * **EOF подмножество EIP, связанное с реализацией) было удалено из обновления Cancun, обновление ****EOF в основном помогает EVM выполняет контроль версий и может одновременно запускать несколько наборов правил контрактов, что поможет последующему расширению Ethereum, но, учитывая осуществимость всего обновления, ** * EOFОбновление может быть перенесено на ежедневное обновление

• 234месяц12***, завершено обновление Ethereum Shanghai;**
• Во время основной встречи разработчиков 13.04.23 разработчики обсудили EIP 4844 (для раскрытия данных о корне состояния CL в EL), для обновления рассматриваются как минимум девять других EIP, а именно EIP 4844**, САМОУНИЧТОЖЕНИЕ УДАЛЕНО (EIP-6780, EIP 4758、ЭИП 6046、ЭИП 6190）、ЭИП 5920、ЭИП 1153、ЭИП 2537、ЭИП 4788、EVMMAX EIP（EIP 6601 и ОИП 6690), СС изменения（EIP 6475、ЭИП 6493、ЭИП 6465、ЭИП 6404 и ЭИП 6466 ）、ЭИП 5656 и****ЭИП 6193**；
• На основном собрании разработчиков 27 и 23 апреля обсуждались некоторые достижения и компромиссы. Во-первых, EIP4844 продолжает определяться для включения в обновление Cancun с добавлением следующих EIP: EIP 6780 (Изменяет функциональность опкода SELFDESTRUCT), EIP 6475 (новый тип простой сериализации (SSZ) для представления необязательных значений), EIP 1153 (добавьте новый код операции для рабочего состояния); во-вторых, EIP, который рассматривается, но официально не включен в обновление, — это EIP. 6913 (введение инструкции SETCODE), EIP 6493 (Определить схему подписи для транзакций с кодировкой SSZ), EIP 4788 (Открыть корень блока цепи маяка в заголовке блока EL), EIP 2537 (добавляет кривую BLS12-381 в качестве предварительной компиляции) и EIP 5656 (вводит новые инструкции EVM для копирования областей памяти); наконец, EOF ** и ** EVMMAX** (** EOF ** зависит от реализации ** * EIP* подмножество) было удалено из обновления Cancun. EOF Обновление было перенесено из Шанхая на конференции разработчиков Ethereum в начале 20231*** и впоследствии было обновлено с * *** С конца 1 до начала 4 в 23**** будет отображаться в обновлении Канкун по умолчанию, но в ** 23** **EOF **был снова удален на собрании разработчиков 29, 4. **

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

235месяц в основном оптимизирует и улучшает детали окончательного предложения,SSZ-> Изменения RLP будут означать, что два SSZ в Канкуне больше не нужны. EIPs, так EIPs 6475 и 6493 будут вывезены из Канкуна для модернизации. В то же время на основном собрании 26 дня Тим Beiko рекомендует, чтобы в будущем разговоры о расширении охвата Канкуна ограничивались следующими пятьюEIP****:EIP-5920 * ,5656,7069,4788 и ****2530 * ****. Теперь разработчики определили полную степень обновления Cancun. ***

*Консенсус Ethereum Core 23 мая 2020 года, на котором обсуждался последний упомянутый EIP. 4788 при добавлении EIP 6987 и ЭИП Обсуждение в 6475, эти два предложения касаются верификаторов и транзакций SSZ соответственно;

• На 161-м заседании исполнительного уровня Ethereum 11 и 23 мая Тим Бейко сказал, что объем обновления Cancun все еще может быть изменен в ближайшие несколько недель, но без явных рекомендаций от разработчиков объем обновления Cancun останется в состоянии «по умолчанию», и обсуждение EIP-4844 показывает что при разработке Автор согласился удалить SSZ из реализации EL EIP-4844, **но это пока не повлияло на дальнейший прогресс 6475. **В дополнение к этому разработчики также кратко обсудили два EIP для рассмотрения в Канкуне, а именно EIP. 6969 (ЭИП

1559. и ЭИП 5656 (эффективные инструкции EVM для копирования областей памяти);

• Изменения в 4844 были кратко обсуждены на собрании разработчиков консенсуса 18 мая 23, например, разрешение приложениям смарт-контракта на EL проверять доказательства состояния CL;
• Деактивация SELFDESTRUCT, изменения спецификации EIP-4844, управление кодами операций и потенциальные окончательные дополнения в Канкуне обсуждались на 162-м собрании Ethereum Core 25 мая 2023 года. Тим Beiko рекомендует, чтобы в будущем разговоры о расширении охвата Канкуна ограничивались следующими пятью EIP: EIP-5920**, 5656, 7069,* ** 4788* ** и ** 2530**. Разработчики подтвердят в ближайшие несколько недель ** Dencun** (****Deneb

• весь ассортимент Канкун****);**

• На 110-й конференции Ethereum Consensus Layer 1 июня 2023 г. исследователь из Ethereum Foundation представил результаты эксперимента по изучению способности узлов основной сети Ethereum распространять большие объемы данных. EIP Спецификация 4844 увеличена с 4 больших двоичных объектов до 6 на блок. В то же время разработчики рассматривают EIP 4788 включены в обновление Cancun;
• На основной встрече разработчиков 13 июня 2023 г. разработчики официально подтвердили объем обновления, включая EIP. 4844、ЭИП 1153、ЭИП 5656、ЭИП 6780、ЭИП 4788；
• На консенсусной встрече 15 июня 2023 г. обсуждалось, какие EIP, ориентированные на CL, следует включить в Deneb, среди которых было предложено добавить EIP-6988, EIP-7044, EIP-7045, и команда клиента CL согласилась к следующему. Тестовая сеть EIP-4844 Devnet6 проверит увеличенное количество больших двоичных объектов и примет окончательное решение по этому вопросу в течение двух недель, в то время как исследователь Ethereum Foundation Майкл Нойдер предложил убрать лимит ставок в 32 ETH, чтобы уменьшить рост активного набора валидаторов;
• На совещании 22 июня 2023 г. tim предложил перенести прекомпилированный адрес 4844 на 0xA, запаковать их и перенести BLS на другой адрес, хотя прекомпилированный через EIP 2537, но в Канкуне его рассматривать не будут;
• На консенсусной встрече 29 июня 2023 г. разработчики продолжили обсуждение количества BLOB-объектов, ограничивая целевой BLOB-объект. Увеличено с 2 до 3, увеличено максимальное ограничение больших двоичных объектов с 4 до 6 и 4844 тестовая сеть Devnet. Скоро будет номер 7.

эта жизнь

• Основной контент — EIP 4844, 即Proto-Danksharding
• Окончательный диапазон EIP для этого обновления Cancun: EIP 4844**、ЭИП 1153、ЭИП 5656、ЭИП 6780、ЭИП 4788. Между тем, на 111-м заседании Ethereum ACDC 19 июня разработчики продолжили обсуждение EIP. 6988、** ЭИП 7044**、**ЭИП 7045 для включения в Deneb. Разработчики заявили, что планируют объединить три вышеупомянутых EIP в спецификацию Deneb в ближайшие недели.

**Анализ КлючаEIP

ЭИП 4844

• Введение:
• Название предложения EIP4844 — Proto-Danksharding, которое является предварительным протоколом для полной версии расширения шардинга Danksharding, Весь набор решений шардинга фактически основан на Rollup для расширения в сети. Цель программы — расширить ** 2 уровень Rollup——, помогая L2 снизить комиссию и увеличить пропускную способность. , прокладывая путь к полному сегментированию ( сегментированию). **
• На телефонной конференции 23 февраля разработчики Ethereum объявят EIP Обновление 4844 называется Deneb, что является именем звезды первой величины в созвездии Лебедя, которое является EIP в соответствующей версии GitHub в будущем. Имя 4844 будет обновлено до Deneb, на встрече 1 23 июня будут внесены некоторые изменения в следующую спецификацию обновления Ethereum, которая называется Deneb на стороне CL и Cancun на стороне EL;
• На собрании разработчиков 23 и 23 июня разработчики подготовились к обновлению EIP. Предварительно скомпилированный адрес 4844. В настоящее время разработчики ядра добавили в EVM 9 прекомпиляций и активируют EIP, 4844 и 4788 создают две прекомпиляции по адресам «0xA» и «0xB» соответственно. На консенсусной встрече 29 июня EIP готов к запуску Выделенная краткосрочная тестовая сеть 4844 Devnet #7。
• EIP-4844** представляет совершенно новый тип транзакции — Blob. Транзакция。** *Профиль блоба:
• Блоб, похож на подключаемый пакет данных, только 128 в начале Место для хранения КБ, в начале обсуждения предложения, цель и предел Блоба были 2/4, и он был скорректирован до 3/6 на собрании разработчиков 9, 23 июня. То есть в настоящее время каждая транзакция в Ethereum может нести до трех транзакций Blob, то есть 384 КБ, цель каждого блока Емкость BLOB-объектов равна 6, то есть 768. КБ, который может содержать до 16 больших двоичных объектов, что составляет 2 МБ;
• Это может иметь определенное влияние на стабильность сети, но команда разработчиков Ethereum все же решила сначала провести тестирование, чтобы избежать необходимости последующих хардфорков для расширения блока больших двоичных объектов.
• Блоб **в ** КЗГ commit Hash В качестве ** Hash, используемого для проверки данных, функция аналогична ** Merkle ;
• Узел синхронизирует Blob в цепочке После транзакции срок действия части BLOB-объекта истечет, и она будет удалена через определенный период времени, а время хранения составит три недели.
• Функция Blob — улучшает TPS Ethereum при одновременном снижении затрат
• В настоящее время общий объем данных всего Ethereum составляет всего около 1 ТБ, а Blob может ежегодно приносить 2,5-5 ТБ дополнительного объема данных в Ethereum, что напрямую намного превышает сам леджер в несколько раз;
• Для узлов загрузка от 1 МБ до 2 МБ данных BLOB-объектов на блок не вызовет нагрузки на полосу пропускания, а объем хранилища только увеличит фиксированный объем данных BLOB-объектов примерно на 200–400 ГБ в течение месяца. Это повлияет на децентрализацию всей системы. Узел Ethereum, но расширение вокруг Rollup значительно улучшено;
• На самом деле самому узлу не нужно хранить все данные BLOB-объекта, потому что BLOB-объект на самом деле является временным пакетом данных, поэтому фактически узлу нужно загрузить только фиксированный объем данных за три недели.
• Роль 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 дней). Решение: **
• Выборка доступности данных (данные Выборка доступности) — снижает нагрузку на узлы
• Разрежьте данные в блобе на фрагменты данных и позвольте узлу перейти от загрузки данных блоба к случайной проверке фрагментов данных блоба, чтобы фрагменты данных блоба были разбросаны по каждому узлу Ethereum, но полные данные блоба храниться во всей книге Ethereum. Предполагается, что количество узлов должно быть достаточным и децентрализованным;
• DAS использует две технологии: код стирания (Erasure Кодирование) и Полиномиальное обязательство KZG (KZG Обязательство);
• Разделение Proposer-Packager (PBS) — Решена проблема разделения труда узлов, пусть узлы с высокопроизводительной конфигурацией отвечают за загрузку всех данных для кодирования раздачи, а узлы с низкопроизводительной конфигурацией отвечают за выборочная проверка проверка.
• Узел с высокопроизводительной конфигурацией может стать сборщиком.Сборщику нужно только загрузить данные блоба для кодирования и создать блок (Block), а затем транслировать его на другие узлы для выборочной проверки.Для сборщика, поскольку синхронизация требования к объему данных и пропускной способности высоки, поэтому он будет относительно централизованным;
• Узел с конфигурацией низкой производительности может стать предлагающим (Proposer), и предлагающему нужно только проверить достоверность данных и создать и транслировать заголовок блока (Block Заголовок), но для предлагающего (Proposer) объем данных синхронизации и требования к пропускной способности невелики, поэтому он будет децентрализован.
• Антицензурный список (crList) — решает проблему, связанную с тем, что упаковщики могут преднамеренно игнорировать определенные транзакции и случайным образом сортировать и вставлять транзакции, которые они хотят получить MEV, из-за их чрезмерной силы проверки.
• Перед тем, как построитель (Builder) упаковывает транзакции блока, предлагающий (Proposer) сначала публикует устойчивый к рецензированию список (crList), который содержит все транзакции в мемпуле;
• Строитель (Builder) может выбрать упаковку и сортировку транзакций только в crList, что означает, что строитель не может вставить свою собственную частную транзакцию для получения MEV, а также он не может намеренно отклонить транзакцию (если только Gas лимит заполнен);
• После упаковки Builder транслирует окончательную версию Hash списка транзакций Proposer, и Proposer выбирает один из списков транзакций для генерации заголовка блока (Block Заголовок) и трансляция;
• Когда узел синхронизирует данные, он получает заголовок блока от предлагающего (Proposer), а затем получает тело блока от упаковщика (Builder), чтобы убедиться, что тело блока является окончательной выбранной версией.
• Двухслотовая PBS — решает проблему, с которой централизованные упаковщики становятся все более и более централизованными, приобретая MEV.
• Используйте режим торгов для определения блока:
• Построитель (Builder) создает заголовок блока списка транзакций после получения crList и ставок;
• Предлагающий (Proposer) выбирает заголовок блока и строителя (Builder), которые в конечном итоге сделали успешную ставку, и предлагающий безоговорочно получает комиссию за выигравшую ставку (независимо от того, сгенерирован ли действительный блок);
• Комитет по верификации (Комитеты) подтверждает заголовок победившего блока;
• Строитель раскрывает тело выигрышного блока;
• Верификационный комитет (Комитеты) подтверждает тело победившего блока и проводит верификационное голосование (если блок пройден, блок будет произведен, а если упаковщик умышленно не отдаст Тело блока, будет считаться, что блока нет).
• Значение:
• Во-первых, у построителя (Builder) больше возможностей для упаковки транзакций, но упомянутый выше crList, во-первых, ограничивает возможность временной вставки транзакций, а во-вторых, если построитель (Builder) хочет нажиться на изменении порядка транзакций, затем в начале необходимо заплатить много затрат на торги, чтобы гарантировать, что он может получить квалификацию главы блока, затем полученная прибыль MEV будет дополнительно уменьшена, и в целом это повлияет на средства и фактическую стоимость. получения МЭВ; *Однако на начальном этапе упаковщиками может стать лишь небольшое количество людей (учитывая проблемы с производительностью нод), а большинство людей станут только оферентами, что может привести к дальнейшей централизации, при этом количество упаковщиков очень мало В случае , некоторые опытные майнеры с возможностями MEV с большей вероятностью сделают успешную ставку, что больше повлияет на фактический эффект решения MEV;
• Имеет некоторое влияние на некоторые решения MEV, использующие аукционы MEV.
• Значение:
• ЭИП 4844 На самом деле очень упрощенная версия Danksharding**: **Он предоставляет тот же интерфейс приложения, что и Danksharding, включая новый код операции под названием Data. Hash и новый объект данных под названием Binary. Крупные объекты, то есть Blob;
• proto-danksharding ** используется для реализации полной ** Danksharding ** спецификации "скоба"** (** формат транзакции и правила проверки****) * * Предложение: Однако сегментирование еще не реализовано, и всем верификаторам и пользователям по-прежнему необходимо напрямую проверять наличие полных данных;
• Почему долгосрочная перспектива выбирает proto-danksharding а не EIP 4488 ** напрямую снижает комиссию ** layer2 , поскольку при обновлении до полного шарда в будущем потребуется лишь небольшая корректировка:
• ОИП Основное практическое различие между 4488 и прото-данкшардингом заключается в том, что EIP-4488 пытается свести к минимуму изменения, которые Эфириум должен внести сегодня, в то время как прото-данкшардинг вносит больше изменений в Эфириум сегодня, чтобы перейти на Эфириум в будущем. требуется для шардинга полной версии;
• Несмотря на то, что добиться полного сегментирования (с выборкой доступности данных и т. д.) — очень сложная задача, и предстоит еще много работы после реализации прото-данкшардинга, эти сложности будут контролироваться на уровне консенсуса. После развертывания proto-danksharding клиентской группе исполнительного уровня, разработчикам сводных пакетов и пользователям не нужно выполнять какую-либо дополнительную работу для перехода к полному сегментированию.
• Для достижения полного сегментирования необходимо завершить фактическую реализацию ** PBS, подтверждение делегирования и выборку доступности данных, но такие модификации будут сконцентрированы в ** CL * * уровень, разработчикам не нужно перенастраивать **: 4844 в настоящее время реализует новый тип транзакции, который точно такой же, как формат транзакции, логика перекрестной проверки консенсуса и логика уровня выполнения, требуемые в полном сегменте, а также производные для больших двоичных объектов , самонастраивающееся независимое ценообразование газа, для достижения полного сегментирования в будущем необходимо завершить фактическую реализацию PBS, доказательство делегирования и выборку доступности данных, но эти модификации относятся только к уровню CL, и не требуют модификации слоя EL или накопительного пакета, что удобно для разработки.

*** а затем ***** САМОУНИЧТОЖЕНИЕ удаление*****,EIP-6780 было окончательно определено как наиболее подходящее решение, но разработчик на 26** В совещание tim** предложило добавить еще один код операции к этому предложениюSETCODE, чтобы позволить программным учетным записям по-прежнему обновляться***

САМОРАЗРУШЕНИЕ удаление EIP-6780**：**X

• фон:
• 21 марта Виталик предположил, что SELFDESTRUCT приносит экологии Эфириума больше вреда, чем пользы.Основная причина в том, что он единственный может изменять бесконечное количество объектов состояния в одном блоке, что приводит к изменению кодов контрактов, и может использоваться без согласия учетной записи. Может изменять код операции баланса учетной записи, что имеет большие скрытые опасности в безопасности Ethereum;**
• Единственный способ удалить контракт в сети — это САМОУНИЧТОЖЕНИЕ. Если вы вызываете функцию самоуничтожения в контракте, вы можете самоуничтожить контракт. Эфириум, хранящийся в контракте, будет отправлен на указанный адрес. Оставшийся код и переменные хранения будут удалены в конечном автомате. На самом деле действие по уничтожению контрактов звучит хорошо в теории, но на самом деле очень опасно. Хотя функция selfdestruct** может помочь разработчикам удалить смарт-контракт и перевести баланс в контракте на указанный адрес в экстренной ситуации, эта функция также используется преступниками, что делает ее средством атаки. **
• На основном собрании разработчиков 13 апреля 23 года для участия в обсуждении были представлены четыре предложения по САМОУНИЧТОЖЕНИЮ, а именно 6780, 4758, 6046 и 6190, и последующий EIP. 6780 был установлен в качестве окончательного предложения.
• Введение: самоуничтожение — это аварийная кнопка смарт-контракта, которая уничтожает контракт и переводит оставшиеся ETH на указанный счет.
• ОИП 6780: Отключить SELFDESTRUCT, если они не находятся в одной и той же транзакции в контракте.
• ОБНОВЛЕНИЕ: 26 мая Тим предложил, помимо удаления SELFDESTRUCT, добавить еще один опкод — SETCODE, чтобы программные учетные записи по-прежнему обновлялись. (то есть добавляется функция обновления, и свойство в смарт-контракте обновляется посредством обновления/апгрейда), здесь происходит поглощение ОИП Преимущества 4758, которые могут дать децентрализованному приложению возможность для обновления.

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

Приведенные ниже три предложения относятся к САМОУНИЧТОЖЕНИЮ, которые впоследствии были удалены в 23год*****4 *** 6780 был официально выбран на основном собрании разработчиков **28, а остальные три предложения были отклонены. заключается в том, что команда разработчиков Ethereum в конечном итоге хочет полностью удалить код операции SELFDESTRUCT, и следующие три предложения в основном изменены путем замены. ***

• EIP-4758 (УСТАРЕЛО): отключите SELFDESTRUCT, изменив SELFDESTRUCT на SENDALL, что восстанавливает все средства вызывающему абоненту (отправляет весь эфир в аккаунте вызывающему абоненту), но не удаляет какой-либо код или хранилище.
• Причина: То же, что и выше, ранее манипулирование кодом SELFDESTRUCT требовало значительных изменений в состоянии учетной записи, таких как удаление всех кодов и хранилища. Это создает трудности для использования деревьев Verkle в будущем: каждая учетная запись будет храниться во многих разных ключах учетной записи, которые не будут явно связаны с корневой учетной записью.
• Изменять:
• Опкод SELFDESTRUCT переименован в SENDALL, теперь только перемещает все ETH в аккаунте вызывающему абоненту, эта схема больше не уничтожает код и хранилище и не изменяет случайные числа;
• Все возвраты, связанные с SELFDESTRUCT, были удалены.
• Значение:
• Сохранена исходная функциональность по сравнению с EIP-6780, потому что некоторые приложения все еще/должны использовать код SELFDESTRUCT.
• EIP-6046 (УСТАРЕЛО): заменить SELFDESTRUCT на DEACTIVATE. Измените SELFDESTRUCT, чтобы не удалять ключ хранилища, и используйте специальное значение в одноразовом номере учетной записи, чтобы указать на деактивацию.
• Причина: То же, что и выше, с деревом Веркле учетные записи будут организованы по-другому: свойства учетной записи (включая хранилище) будут иметь отдельные ключи, но будет невозможно пройти и найти все используемые ключи. Манипулирование кодами SELFDESTRUCT ранее требовало обширных изменений в состоянии учетной записи, что очень затрудняло дальнейшее использование SELFDESTRUCT в деревьях Verkle.
• Изменять:
• Изменить правила, введенные EIP-2681, чтобы увеличение обычного одноразового номера ограничивалось 2^64-2 вместо 2^64-1;
• САМОРАЗРУШЕНИЕ изменено на:
• Не удаляйте никаких ключей хранения и оставьте учетную запись на месте;
• Переведите баланс счета на цель **, ** установите баланс счета на 0.
• Установите одноразовый номер учетной записи на 2^64-1.
• Нет возврата с EIP-3529;
• Соответствующее правило SELFDESTRUCT для EIP-2929 остается без изменений.
• Значение:
• Это предложение более гибкое, чем другие варианты прямого удаления SELFDESTRUCT.
• EIP-6190 (УСТАРЕЛО): Изменено САМОУНИЧТОЖЕНИЕ, совместимое с Verkle, так что оно вызывает только ограниченное количество изменений состояния.
• Причина: То же, что и выше, с деревьями Веркле учетные записи будут организованы по-другому: свойства учетной записи (включая хранилище) будут иметь отдельные ключи, но будет невозможно пройти и найти все используемые ключи. Манипулирование кодами SELFDESTRUCT ранее требовало обширных изменений в состоянии учетной записи, что очень затрудняло дальнейшее использование SELFDESTRUCT в деревьях Verkle.
• ИЗМЕНЕНО: Вместо уничтожения контракта в конце транзакции в конце транзакции, которая его вызвала, происходит следующее:
• Код контракта установлен на 0x1, а случайное число установлено на 2^64-1.
• 0-й слот хранения контракта устанавливается для контракта с помощью кода операции CREATE ( keccak256(contractAddress, nonce)) будет выдан, когда адрес. Случайное число всегда 2^64-1.
• Если контракт самоуничтожается после переадресации вызова одним или несколькими контрактами псевдонимов, установите 0-й слот хранения контракта псевдонимов на адрес, рассчитанный на шаге 2;
• Баланс контракта будет полностью переведен на адрес вверху стека;
• Верхняя часть стека выталкивается.
• Значение:
• Разработан, чтобы позволить SELFDESTRUCT впоследствии формировать деревья Веркле с минимальными изменениями;
• Стоимость газа увеличилась с применением EIP-2929.

*** Далее идет ***** EIP 1153******, экономя при этомгаз*, прокладывая путь к будущим конструкциям хранения***

ЭИП 1153Х

• Кратко: промежуточные коды операций хранения, добавьте коды операций для управления состоянием, которое ведет себя так же, как сохраняет, но отбрасывает после каждой транзакции.
• причина:
• Выполнение транзакции в Ethereum может генерировать несколько вложенных фреймов выполнения, каждый фрейм создается с помощью инструкции CALL (или аналогичной). Контракты могут быть повторно введены в одну и ту же транзакцию, и в этом случае более одного фрейма принадлежит одному контракту.
• В настоящее время эти фреймы могут обмениваться данными двумя способами: ввод/вывод с помощью инструкций CALL и через сохранение обновлений. Связь через ввод-вывод небезопасна, если существует промежуточная структура, принадлежащая другому ненадежному контракту.
• с повторным входом lock, он не может полагаться на промежуточные кадры для передачи состояния блокировки: связь SSTORE через хранилище SLOAD обходится дорого, а временное хранилище — это выделенное и экономичное решение проблемы межкадровой связи.
• Изменено: в EVM добавлены два новых кода операции, TLOAD (0xb3) и TSTORE (0xb4).
• Временное хранилище является частным для контракта, которому оно принадлежит, точно так же, как и постоянное хранилище, только владеющая структура контракта может получить доступ к его временному хранилищу. При доступе к хранилищу все фреймы обращаются к одному и тому же эфемерному хранилищу так же, как и к постоянному хранилищу, но иначе, чем к памяти.
• Возможные варианты использования:
• повторный вход замок;
• Адреса CREATE2, вычисляемые в цепочке: параметры конструктора считываются из фабричного контракта, а не передаются как часть хэша кода инициализации;
• Утверждение EIP-20 для одной транзакции, например #temporaryApprove(адрес транжира, сумма uint256);
• Контракт на комиссию за перевод: платите комиссию за контракт на токен, чтобы разблокировать переводы во время транзакций;
• Режим «Till»: позволяет пользователю выполнять все действия в рамках обратного вызова и проверяет, сбалансировано ли «till» в конце;
• Метаданные вызова прокси: передача дополнительных метаданных для реализации контрактов без использования данных вызова, таких как значения неизменяемых параметров конструктора прокси.
• Значение:
• Экономьте газ** благодаря более простым** газовым правилам выставления счетов;**
• ** Решить проблему межкадровой связи; **
• ** Не изменять семантику существующих операций **
• ** Нет необходимости очищать резервуар для хранения после использования; **
• ** Будущие проекты хранения (такие как ** Verkle ** деревья) не требуют возмещения за мгновенное хранение. **

Вслед за 4788 это может снизить доверие к залоговому пулу**

ЭИП 4788**：**Х

• Введение: корень блока маяка в EVM. *Обновление: на встрече разработчиков 15 июня 23 июня разработчики предложили внести изменения в код, чтобы улучшить взаимодействие со стейкерами. Этот EIP раскроет корень блока цепочки маяка, который содержит информацию о состоянии внутренней цепочки EVM, для разработки DApp. доверие автора минимизирует доступ.
• ИЗМЕНЕНО: Зафиксируйте хеш-корни каждого блока цепочки маяков в соответствующем заголовке полезной нагрузки выполнения, сохраните эти корни в контракте в состоянии выполнения и добавьте новый код операции для чтения этого контракта.
• Значение: ** Это предложение по модификации кода, в котором предлагается модифицировать виртуальную машину Ethereum (EVM), чтобы она могла отображать состояние уровня контракта (CL). root Данные на уровне выполнения (EL) могут сделать связь между различными протоколами и приложениями в сети Ethereum более эффективной и безопасной****. ** Разрешить более ненадежные проекты для пулов ставок, протоколов мостов и повторных ставок.

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

ЭИП 5656Х

• Введение: MCOPY

• Инструкция копирования памяти. Обновление: 09.06.23, команда разработчиков заявила, что изначально они разделились по поводу MCOPY, потому что, хотя это решило проблему безопасности, они все еще были обеспокоены добавлением его к полосе пропускания для реализации и тестирования, необходимой для обновления, но в конце концов согласились включить EIP, но будет рассматриваться возможность удаления, если разработчик обнаружит проблемы с емкостью при тестировании или на стороне клиента. Таким образом, MCOPY* временно включен в обновление Cancun. **

• Изменено: предоставлена эффективная инструкция EVM для копирования областей памяти.
• Значение: копирование памяти — это базовая операция, но ее реализация на EVM требует затрат.
• Наличие инструкции MCOPY позволяет более точно копировать кодовые слова и предложения, что повысит производительность копирования в память примерно на 10,5%, что очень полезно для различных операций с интенсивными вычислениями;
• Компиляторам также будет полезно генерировать более эффективный и меньший байт-код;
• Это может сэкономить определенное количество предварительно скомпилированных расходов на газ, но на самом деле это не может способствовать реализации этой части.

Шорт-лист****EIP

236месяц15** консенсусное собрание разработчиков обсуждалось в *** Который EIP** с центром CL включены в Deneb, где **** ** EIP 6988*****、ЭИП 7044、ЭИП 7045* предлагается присоединиться. ***

ЭИП 6988**：**Х

• Краткое описание: Предотвратите избрание валидаторов с косой чертой в качестве предлагающих блоки.
• Значение: Увеличение штрафов за нарушение узлов пойдет на пользу DVT.

ЭИП 7044**：**Х

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

ЭИП 7045**：**Х

• Введение: будет аттестация Диапазон включения слотов простирается от скользящего окна в одну эпоху до двух эпох.
• Значение: Повышение безопасности сети.

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

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

EVMMAX EIP**：**

• Кратко: EVMMAX стремится повысить гибкость арифметических операций и схем подписи в Ethereum. В настоящее время существует два предложения EVMMAX: одно с EOF и одно без EOF.
• ОИП 6601: Модульные арифметические расширения EVM (EVMMAX)
• Изменение: EIP 5843 итерации, с EIP Отличие 5843:
• 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.

ЭОФ изменения**:**

• Введение: EOF — это обновление EVM, которое вводит новые стандарты контрактов и некоторые новые коды операций.Традиционный байт-код EVM (байт-код) представляет собой неструктурированную последовательность инструкций (неструктурированный последовательность инструкций) байт-код. EOF представляет концепцию контейнера, который реализует структурированный байт-код. Контейнер состоит из заголовка и нескольких разделов для структурирования байт-кода. После обновления EVM сможет осуществлять контроль версий и одновременно запускать несколько наборов правил контрактов.
• ОИП 663：
• Кратко: Неограниченные инструкции SWAP и DUP *Значимость: Путем введения двух новых инструкций: SWAPN и DUPN, которые отличаются от SWAP и DUP увеличением глубины стека с 16 элементов до 256 элементов.
• ОИП 3540：
• Введение:
• Раньше байт-код EVM, развернутый в цепочке, не имел предопределенной структуры, и код проверялся только перед запуском в клиенте.Это не только косвенные затраты, но и мешает разработчикам внедрять новые функции или устаревшие старые функции.
• Этот EIP вводит контейнер, который может быть расширен и контролируется версиями для EVM, и объявляет формат контракта EOF.На основании этого код может быть проверен при развертывании контракта EOF, то есть создании Проверка времени означает, что контракты, которые не соответствуют формату EOF, могут быть предотвращены от развертывания.Это изменение реализует контроль версий EOF, который поможет отключить существующие инструкции EVM или ввести крупномасштабные функции (например, абстракцию учетной записи) в будущем. .
• Значение:
• Контроль версий способствует внедрению или отказу от новых функций в будущем (например, введение абстракции учетной записи);
• Разделение кода контракта и данных выгодно для проверки L2 (op), снижая стоимость газа валидаторов L2.В то же время разделение кода контракта и данных также более удобно для работы анализа данных в цепочке инструменты.
• ОИП 3670：
• Введение: на основе EIP-3540 цель состоит в том, чтобы гарантировать, что код контракта EOF соответствует формату и действителен, а развертывание контрактов, которые не соответствуют формату, будет предотвращено, не затрагивая Legacy. байткод。
• Значение: на основе контейнера, представленного 3540, EIP-3670 гарантирует, что код в контракте EOF действителен, или предотвращает его развертывание. Это означает, что неопределенные коды операций не могут быть развернуты в контрактах EOF, что дает дополнительное преимущество, заключающееся в уменьшении количества версий EOF, которые необходимо добавить.
• ОИП 4200：
• Введение:
• Представлены первые специфичные для EOF коды операций: RJUMP, RJUMPI и RJUMPV, которые кодируют назначения как подписанные непосредственные значения. Компиляторы могут использовать эти новые коды операций JUMP для оптимизации стоимости газа при развертывании и выполнении JUMP, поскольку они устраняют необходимость в существующих кодах операций JUMP и JUMPI для выполнения jumpdest. Время работы, необходимое для анализа. Этот EIP предназначен для динамического Добавление прыжка.
• По сравнению с традиционными операциями JUMP разница в том, что такие операции, как RJUMP, не задают конкретное положение смещения, а задают относительное положение смещения (из динамического прыжки -> статические прыжки), потому что много раз статические прыжков достаточно.
• Значение: оптимизировать сеть и снизить затраты.
• ОИП 4750：
• Продвиньте функцию 4200 на один шаг вперед: представив CALLF Два новых кода операции и RETF реализуют альтернативное решение для ситуации, которое нельзя заменить RJUMP, RJUMPI и RJUMPV, так что JUMPDEST больше не нужен в контракте EOF, поэтому динамический запрещен. Прыгать.
• Значение: оптимизировать код, разделив код на несколько частей.
• ОИП 5450：
• Предыстория: Предыстория по-прежнему заключается в том, что контракт Ethereum не проверяется при его развертывании, а выполняется только серия проверок при его запуске, не переполняется ли стек (верхний предел 1024), достаточно ли газа, и так далее.
• Содержание: Добавлена еще одна проверка действительности контрактов EOF, на этот раз вокруг стека. Этот EIP предотвращает ситуации, когда развертывание контракта EOF может привести к потере или переполнению стека (стек недолив/перелив). Таким образом, клиенты могут сократить количество проверок достоверности, которые они выполняют во время выполнения контрактов EOF.
• Важность: большое улучшение заключается в том, чтобы сделать эти проверки во время выполнения как можно меньше, а при развертывании контракта — больше проверок.

5месяц26********************************* ******************************************************* ******************************************* 4844Связанное изменение типа транзакции с SSZ на RLP означает отсутствие необходимости в двух жках Канкуна ССЗ EIPs, так EIPs 6475 и 6493* вывезены из Канкуна для модернизации***

ЭИП 6475Х

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

ЭИП 6493Х

• Введение: схема подписи транзакций SSZ. Этот EIP определяет схему подписи для закодированных транзакций с простой сериализацией (SSZ) и определяет, как узлы должны обрабатывать типы транзакций больших двоичных объектов, которые отформатированы в формате SSZ на CL, но кодируются по-разному на EL. Этот EIP является частью обновления формата сериализации Ethereum для межуровневой согласованности;
• Фон: ССЗ изменения
• Введение: простой SerialiZe — это метод сериализации, используемый в цепочке маяков.
• SS Изменения также включают три других вспомогательных предложения, на этот раз было введено только 6465.
• ОИП 6465: корень вывода SSZ, определяет существующую Merkle-Patricia Миграция обязательств Trie (MPT) на снятие средств с простой сериализации (SSZ);
• ОИП 6404 / ОИП 6466：
• Оба определяют существующую модель Merkle-Patricia. Промисы Trie (MPT) находятся в процессе перехода на простую сериализацию (SSZ).
• ЭИП-6404 — корень транзакции SSZ
• ЭИП-6466 — основание получения ССЗ

Тим Beiko** предложила дальнейшие разработки, связанные с расширением Канкуна, на основной встрече разработчиков, которая состоится 5месяц26***. ограничено следующими пятьюEIP*:EIP 5920*,5656,7069,4788 и ***2537, в рамках этой области будут созданы последующие предложения. Последующие действияEIP 5656 и ЭИП 4788 было подтверждено как официальное предложение по обновлению, ***** 5920 , ****** 7069 ***** и ***** 2537. удалено, гдеEIP 5920 связано с беспокойством разработчика о возможных побочных эффектах способа передачи ETH, а также с незавершенными рассуждениями, тестированием и работой по безопасности, поэтому от обновления удалять. ***

ЭИП 5920**：**Х

• Введение: платежный код операции. Представляет новый код операции PAY для переводов Ethereum, который отправляет эфир на адрес без вызова каких-либо его функций.
• Причина: В настоящее время для отправки эфира на адрес требуется, чтобы пользователь вызывал функцию по этому адресу, что имеет несколько проблем:
• Во-первых, это открывает вектор для повторных атак, поскольку получатель может перезвонить отправителю;
• Во-вторых, он открывает DoS-вектор, поэтому родительская функция должна знать, что у получателя может закончиться газ или обратный вызов;
• Наконец, код операции CALL излишне дорог для простых эфирных передач, так как требует расширения памяти и стека, загрузки полных данных получателя, включая код и память, и, наконец, требует выполнения вызова, возможно, выполняя другие действия непреднамеренно.
• Изменять:
• Введен новый код операции: ( PAY) PAY_OPCODE, где:
• Извлечь два значения из стека: addrthen val.
• Перенести wei с адреса исполнения val на адрес addr. Если адрес нулевой, valwei будет запрограммирован с адреса выполнения.
• Возможные подводные камни: Существующие контракты будут использоваться независимо от фактического баланса их кошелька, так как уже можно отправить эфир на адрес без звонка.
• Значение: экономить газ**. ** *Обновление: 06.09.23 PAY был удален из обновления из-за опасений по поводу возможных побочных эффектов способа передачи ETH, а также из-за обоснования, тестирования и работы по обеспечению безопасности, необходимых для принятия предложения.

ЭИП 7069Х

• Введение: модифицированная инструкция CALL
• ИЗМЕНЕНО: Введены три новые инструкции вызова, CALL2, DELEGATECALL2 и STATICCALL2, которые упрощают семантику. Направлена на то, чтобы убрать наблюдаемость газа из новой директивы и открыть дверь для нового класса контрактов, на которые не влияет переоценка.
• фон:
• Правило 63/64: ограничьте глубину вызова и убедитесь, что у вызывающего абонента есть оставшийся газ для внесения изменений в состояние после возврата вызываемого абонента;
• До того, как были введены правила 63/64, требовался несколько более точный расчет доступного газа вызывающего абонента. В Solidity есть сложное правило, которое пытается оценить стоимость выполнения самого вызова на стороне вызывающей стороны, чтобы установить разумное значение газа.
• **В настоящее время вводятся **63/64th Правила:
• Убрана проверка глубины захода;
• Обязательно зарезервируйте не менее 5000 газа перед выполнением вызванного поведения;
• Убедитесь, что для вызываемого поведения доступно не менее 2300 газа.
• Правила субсидии: например, известная субсидия 2300, когда контракт вызывает другой контракт, вызываемый контракт получает 2300 газ используется для выполнения очень ограниченных операций (достаточно, чтобы сделать небольшой расчет и создать журнал, но недостаточно, чтобы заполнить слот хранилища), и, поскольку он устанавливает фиксированное количество газа, люди не могут определить его как пока цена на газ может быть скорректирована Какой тип расчетов может поддерживать газ?
• Значимость: ** Открывает путь для внедрения ** EOF ** в будущем и более удобен для работы с крупными контрактами. **
• Удалена опциональность газа: новые директивы не позволяют указывать газ ограничивать, но полагаться на «правило 63/64» (в основном относящееся к переоценке газа для большого количества операций ввода-вывода в EIP-150, что увеличивает потребление газа для конкретных операций) для ограничения газа, это важное улучшение для упрощения окружающего правила «Допуск», независимо от того, отправляется значение или нет, вызывающему абоненту не нужно выполнять расчеты, связанные с газом;
• После введения нового предложения пользователи всегда могут преодолеть Out, отправив больше газа в транзакции (конечно, при условии соблюдения лимита газа на блок) ошибки газа.
• Раньше при повышении стоимости хранения (например, EIP-1884 увеличивал газ для определенных кодов операций) некоторые контракты, которые отправляли только ограниченное количество газа на свои вызовы, нарушались новым механизмом расчета стоимости. Ранее в некоторых контрактах была газовая шапка, которая постоянно ограничивала количество газа, которое они могли потратить, даже если они отправляли его в свои дополнительные вызовы, это не срабатывало, независимо от того, сколько дополнительного газа они отправляли, потому что вызов ограничивал бы сумма отправлена.
• Проложите путь к внедрению EOF: как только будет введен формат объекта EVM (EOF), старые инструкции по вызову могут быть отклонены в контракте EOF, гарантируя, что они в значительной степени невосприимчивы к изменениям цен на газ. Поскольку эти операции необходимы для устранения наблюдаемости газа, EOF потребует их вместо существующих инструкций;
• Более удобные коды возврата статуса: введены удобные функции, которые возвращают более подробные коды статуса: успех (0), восстановление (1), сбой (2) и могут быть расширены в будущем.

ЭИП 2537**：**Х

• Введение: предварительная компиляция обработки кривой BLS12-381.
• Изменено: добавлены операции с кривой BLS12-381, предварительно скомпилированные в набор, необходимый для эффективной проверки подписи BLS, проверки SNARK и т. д. операций. Значимость: Эфириум может создавать более надежные криптографические доказательства и обеспечивает лучшую совместимость с цепочкой маяков*. **

PR 3175 *** Упоминается, но не включен в шорт-лист, дальнейшего обсуждения нет ***

PR 3175**：**Х

• Кратко: это предложение не позволит оштрафованным валидаторам предлагать блоки, когда они исключены из очереди. Если более 50% валидаторов будут оштрафованы за злонамеренное поведение, эти валидаторы по-прежнему смогут предлагать блоки при принудительном удалении из сети. Изменение этой логики является относительно незначительным изменением уровня CL, которое обеспечивает защиту от «режимов с высоким уровнем отказов», говорят разработчики.
• По данным 108-го консенсусного собрания разработчиков Ethereum Core, состоявшегося 4 мая, PR 3175 находится в процессе форматирования как EIP и будет изменен на EIP-6987, что по соображениям безопасности предотвращает выбор валидаторов с косой чертой в качестве предлагающих блоки.

будущее

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

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

• Нет сомнения, что расширение является первым приоритетом (4844);
• Безопасность и экономия газа стоят на втором месте (6780, 1153, 5656 и 7045), при этом учитывается определенный опыт разработчиков;
• Третье — совместимость, например, оптимизация соединения, связи и взаимодействия между децентрализованными приложениями (4788, 7044 и 6988);
• Ожидаемые данные: тестовая сеть 4844 может уменьшить противоположную сторону 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, EIP 4844 вводит большие двоичные объекты данных в качестве дополнительного пространства данных, уникального для накопительных пакетов, что значительно снижает затраты на хранение и тем самым снижает затраты на DA.
• **Фактическое время посадки велико, а улучшенный ** TPS ** и уменьшенный ** газ ** по-прежнему ограничены, так что это хорошо для ** DA * * проекты слоев в последующем продолжении разработки: **
• могу рассказать о данкшардинге в полынье В статье о шардинге данных безопасности указано, что на внедрение потребуется 2-5 лет;
• ** Даже если он приземлится, он может увеличить ** TPS ** и уменьшить ** газ ** величины по-прежнему ограничены:**
• ОИП 4844 в настоящее время поддерживает 6 больших двоичных объектов, и проблема будущего расширения может быть решена только с помощью Danksharding;
• Текущее пространство блоков Ethereum составляет около 200 КБ. После Danksharding запланированный размер в спецификации составляет 32 мегабайта, что примерно в 100 раз больше. В настоящее время TPS Ethereum составляет около 15. В идеализированном состоянии он будет около 1500 после увеличения в 100 раз, что не является большим улучшением по величине.
• Поэтому долго ждать + Ограниченные фактические изменения принесут пользу DA Проекты слоев, например Celestia, ** Eigenda** ** ** DA ** проект все еще может пройти дешевле и быстрее ** TPS ** чтобы конкурировать с ** Danksharding ** в будущем , ETHхранилище Topia* и другие новые проекты DA также могут заполнить пробел на рынке перед посадкой. **
• ** Также необходимо решить технические вопросы, такие как проблемы с хранением и доступностью данных: **
• Есть две основные затраты на DA, одна — это стоимость пропускной способности сети, другая — стоимость хранилища, и сам по себе 4844 не решает проблему хранения и проблему пропускной способности цепочки блоков.
• Блоб будет храниться на уровне консенсуса Ethereum в течение примерно 3 недель, а затем удален.Если вы хотите хранить полные исторические записи и сделать все данные доступными, текущие решения включают в себя: само dapp хранит данные, связанные с ним, и портал Ethereum сеть (в настоящее время находится в разработке) или сторонние протоколы, такие как обозреватели блоков, исторические данные в BitTorrent или спонтанное хранение отдельными пользователями.
• Таким образом, Proto-Danksharding выиграет протокол хранения, модульный протокол и сеть расширения хранилища L1:
• Спрос на вызов исторических данных приведет к новому каналу разработки для протоколов децентрализованного хранения или сторонних индексных протоколов;
• Последующие модульные соглашения могут выполнять транзакции через высокоскоростной накопительный пакет, уровень безопасного расчета отвечает за расчет, а уровень доступности данных с низкой стоимостью и большой емкостью отвечает за гарантию;
• Хорошая сеть расширения хранилища L1, такая как Eth хранилище, которое может предоставить решение второго уровня для программируемого хранилища с более низкой стоимостью хранения.

**3.**Канкунский апгрейд дает преимущества L2разнообразия, L3, RAAS и Доступность данных и другие треки

• Анализ дорожки L2:
• Головной уровень 2, такой как Arbitrum Орбита, ОП Стек, Полигон 2.0, Фрактал 5 проектов, включая Scaling (под StarkWare) и HyperChain (под zkSync), выиграют. Снижение платы за хранение, вызванное большим двоичным объектом, сделает предыдущую серию ограниченного слоя 2 Стоимость разработки и проблемы масштабируемости были значительно улучшены, а пропускная способность значительно увеличилась.После решения проблемы стоимости головной уровень 2 Будет возможность продолжить развертывание высоконастраиваемой многоцепочечной параллельной среды L3 для определенных функций;
• Разрыв в операционных расходах между Layer2 второго уровня и основным Layer2 будет сокращен, что даст больше возможностей для развития некоторым небольшим проектам, таким как Aztec, Metis, Boba, ZKspace, layer2.finance и т.д.;
• Хотя реальные потребности модульных блокчейн-проектов еще предстоит проверить, по-прежнему возможны различные языки программирования, такие как Cario от Starkware, языки серии Move, языки серии C, C++, C# и Go, поддерживаемые Wasm, которые могут представить больше разработчиков web2.
• Анализ дорожки Рааса:
• Преимущество самого Raas заключается в его высокой степени настройки, индивидуальных требованиях > чистой стоимости и эффективности, поэтому снижение затрат является большим преимуществом настроенного Rollup.
• Но проблема с дорожкой RAAS в том, что она может быть OverHype, и есть даже сомнения по поводу самой дорожки RAAS. ** Столкнувшись с конкуренцией ** 5 ** голов** layer2 **, появлением различных новых ** DA **, могут ли новые проекты составить знак вопроса на треке. **
• Во-первых, слой заголовка 2 Преимущество развертывания цепочки приложений заключается в целостности сетевого каркаса и безопасности экологии между цепочками, а преимущество RAAS — в его кастомизации и свободе;
• Тем не менее, технические барьеры RAAS серий OP и ZK в настоящее время не сильны, и в краткосрочной перспективе они все еще находятся на стадии тестовой сети, и фактического взаимодействия продуктов нет.Учитывая фактический прогресс RAAS, технических форм и экологические преимущества layer3 в будущем, фактическая потребность RAAS сомнительна.
• Отдел ОП: Хотя ОП апгрейд стека+ Запуск 4844 привел к небольшому увеличению стоимости и эффективности, но это увеличение не очень привлекательно;
• Серия ZK: В настоящее время многие ведущие проекты следуют маршруту ZKEVM и уделяют больше внимания совместимости с Ethereum, поэтому дизайн схемы принесет в жертву определенную эффективность, и он не так целенаправлен, как серия OP. Но ZK в настоящее время на рынке Большинство RAAS по-прежнему используют ведущие проекты (такие как ZkSync) для разветвления цепочки, и барьеры все еще не сильны.
• ТАК, краткосрочно ОП RAAS** **Еще есть место для развития до того, как ** layer3 ** приземлится. В долгосрочной перспективе ** ZK RAAS ** и ** layer3 ** могут стать трендом в будущем. **
• ЗК RAAS имеет больший недостаток в стоимости после 4844, и он потребляет гораздо больше вычислительной мощности, чем OP.Хотя стоимость загрузки на L1 меньше, чем у OP, это всего лишь капля в море по сравнению со стоимостью процесса доказательства, в то время как OP Преимущество в том, что он может быстро построить экологию за короткий промежуток времени, и еще есть место для развития до того, как приземлится слой 3;
• Для обычных приложений defi и рынков NFT трансформация накопительного пакета не является жестким требованием.Только платежные приложения или игры, требующие высокой эффективности, имеют более высокий спрос на накопительный пакет. В будущем проекты defi могут быть на уровне 2, социальные проекты могут быть на уровне 3 или вне сети, и, наконец, основные данные и отношения будут размещены на уровне 2. Игровые проекты должны быть переведены на уровень 3 или объединены, но, учитывая, что большая часть текущих цепные игры — это, по сути, фонды, и невозможность внешней циркуляции токенов привела к узким местам в разработке, в сочетании с появлением игр во всей цепочке, экологическая привлекательность самого l3 намного выше, чем у накопительного.

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

• Канкун обновляет второе важное предложение САМОУНИЧТОЖЕНИЕ удаление еще больше улучшит безопасность Ethereum.В то же время, для возможных программных проблем с обновлением учетной записи после удаления подготовлен новый код операции SETCODE для улучшения этой ситуации;
• Третье предложение EIP для обновления Cancun 1153 добавляет код операции временного хранилища, который может, во-первых, экономить газ, во-вторых, решать проблему межкадровой связи и, наконец, прокладывать путь для будущего дизайна хранилища, такого как дерево Веркле, в котором не нужно будет учитывать проблему возмещения переходных процессов. хранилище;
• Четвертое предложение EIP для обновления Cancun 5656 вводит инструкцию копирования памяти MCOPY, которая может более точно копировать кодовые слова и предложения, что улучшит производительность копирования памяти примерно на 10%;
• Пятое предложение по обновлению Канкуна — EIP. 4788 может сделать связь между различными протоколами и приложениями в сети Ethereum более эффективной и безопасной, а также обеспечить более ненадежные конструкции для залоговых пулов, мостов и протоколов перестейкинга;
• Канкун обновляет последние (15, 23 июня) предложенные обновления EIP, ориентированные на CL: EIP 6988、ЭИП 7044、ЭИП 7045, который улучшает безопасность и удобство использования Ethereum в деталях, например, улучшает опыт залогодателей и повышает безопасность сети.
• Среди удаленных предложений ССЗ-> Преобразование RLP делает две SSZ ЭИП (ЭИП 6475 и ЭИП

6493. был удален из обновления Cancun; предложения, связанные с EOF, были удалены из обновления Cancun после того, как были удалены из обновления Shanghai, и в настоящее время считается, что они могут быть непосредственно реализованы в более позднем ежедневном обновлении; EVMMAX связан с некоторыми EIP связанный с подмножеством реализации EOF, поэтому он также был перемещен из Канкуна для обновления вместе с EOF; учитывая потенциальные побочные эффекты, которые могут существовать на пути передачи ETH, а также обоснование, тестирование и работу по обеспечению безопасности, необходимые для принятия предложения , ЭИП 5920 удален из обновления.

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

Небольшой эффект на zkml

• ZKML — доказательство с нулевым разглашением (Zero Знание) и машинное обучение (Machine Learning); сочетание **блокчейна и ML модели решает проблемы защиты конфиденциальности и верифицируемости машинного обучения:
• Защита конфиденциальности: конфиденциальность входных данных, например, использование большого количества личной информации в качестве данных для подачи на машину для обучения, конфиденциальность личной информации является основным требованием, или параметры модели являются основной конкурентоспособностью проекта, и шифрование также необходимо для поддержания барьеров конкуренции. Когда существуют такие проблемы с доверием, модели машинного обучения не могут получать крупномасштабные данные и приложения.
• Проверяемость: технология доказательства с нулевым разглашением имеет широкий спектр применений, а ZKP позволяет пользователям узнать правильность информации без проверки. А поскольку модель машинного обучения требует большого количества вычислений, модель машинного обучения может генерировать доказательства с помощью ZK-SNARK, уменьшая размер доказательства и уменьшая потребность в вычислительной мощности машинного обучения.
• Требования к хранению ZKML ** имеют мало общего с ** DA **: **Нужно что-то вроде Space Основной технологией этой отдельной структуры хранения является новый протокол безопасности «SQL proof». Проще говоря, это хранилище данных рядом с блокчейном, позволяющее разработчикам подключаться в сети и вне сети в простом формате SQL. загружать результаты прямо в смарт-контракт;
• ZK-SNARKs **является основной формой ** ZK ** в ** ZKML ** и может адаптироваться к ончейн-расчету ** **ML ** ** С развитием криптографии, особенно рекурсивной **SNARK доказательство будет выгодно ZKML Посадка в цепочку:
• ZK-SNARKs характеризуются высокой компактностью.Использование ZK-SNARKs позволяет доказывающему сгенерировать короткое доказательство, а верификатору не нужно взаимодействовать, и ему достаточно выполнить небольшой объем вычислений для проверки его достоверности.Этот вид доказательства требуется только один раз Характер взаимодействия между верификатором и верификатором делает ZK-SNARK эффективным и практичным в практических приложениях и больше подходит для требований вычислительной мощности ML в цепочке.
• В настоящее время обучение в цепочке невозможно, и в цепочке могут храниться только результаты вычислений вне цепочки:
• Текущая проблема ML в большей степени связана с неудовлетворенными требованиями к вычислительной мощности и низкой производительностью, вызванной ограничениями алгоритма (нельзя рассчитывать параллельно) Крупномасштабная модель ZK доказывает, что требуется более высокая вычислительная мощность, которую нельзя поддерживать в цепочке , Текущие популярные ZK-SNARK поддерживают только доказательство с нулевым разглашением ML с небольшим масштабом и небольшим объемом вычислений, то есть ограничение вычислительной мощности является ключевым фактором, влияющим на разработку приложений блокчейна ZKML, и цепочка может хранить только результаты вычислений вне сети.

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

• Во-первых, апгрейд Cancun может в некоторой степени уменьшить ZK накопительный пакет Подтверждение оплаты:
• Текущая комиссия за транзакцию zkSync зависит от 3 аспектов:
• Стоимость фиксированных ресурсов, потребляемых верификатором для создания доказательств SNARK и их проверки, относительно высока;
• Плата за газ, когда верификатор отправляет доказательство SNARK в основную сеть Ethereum, эта часть платы будет соответственно увеличиваться из-за перегрузки основной сети;
• Сервисный сбор, уплачиваемый пользователем верификатору, включая подтверждение транзакции, трансляцию сообщения и т. д.
• Таким образом, при введении 4844 будет снята проблема повышения платы за газ из-за перегруженности магистральной сети, а также в определенной степени может быть снижена стоимость пруфов ЗКП, хотя это не так много по сравнению со стоимостью генерации пруфов, учитывая, что ZK все еще находится на ранней стадии, нельзя недооценивать будущую тенденцию развития серии ZK.
• Во-вторых, абстракция учетной записи преобразует традиционные ** tx ** транзакции в ** useroperation, а затем ** useroperations use ECDSA * * Упаковано в блоки, хранилище в цепочке занимает больше, чем раньше, поэтому требования к хранилищу выше;
• **Далее абстрагирование аккаунта и ** ЗК накопитель могут дополнять друг друга:
• Текущая проблема абстракции аккаунта - Газ Плата дорогая, потому что слишком много шагов и задействованы смарт-контракты, поэтому данных много, что приводит к газу. Плата дорогая, а ЗК Преимущество Rollup в том, что он может уменьшить объем данных;
• Абстракция учетной записи затрудняет обеспечение безопасности: поскольку AA включает в себя несколько контрактов, безопасность является проблемой, но после постепенного формирования L2 в будущем уровень консенсуса не изменится, смарт-контракты будут иметь больше применений, а безопасность абстракция аккаунта также может быть гарантирована с помощью ZK Надежная проверка свертки еще больше улучшит безопасность.
• **Наконец, учитывая развитие технологии ** AI , она может помочь повысить безопасность контрактов в сети и оптимизировать транзакции или этапы деятельности в сети:
• ИИ и безопасность: технологию ИИ можно использовать для повышения безопасности и защиты конфиденциальности внутрисетевых транзакций. Например, платформа безопасности Web3 SeQure использует ИИ для обнаружения и предотвращения злонамеренных атак, мошенничества и утечки данных, а также предоставляет механизмы мониторинга и сигнализации в реальном времени для обеспечения безопасности и стабильности транзакций в цепочке;
• ИИ и оптимизация действий в цепочке: Действия в цепочке включают транзакции, выполнение контрактов и хранение данных. Благодаря возможностям интеллектуального анализа и прогнозирования ИИ можно лучше оптимизировать действия в сети, а также повысить общую эффективность и производительность. ИИ может помочь определить шаблоны транзакций, обнаружить необычную активность и предоставить рекомендации в режиме реального времени для оптимизации распределения ресурсов для сетей блокчейна посредством анализа данных и обучения моделей.
• **Поэтому апгрейд Cancun будет от расширения места для хранения до интеграции с ** ZK Взаимодополняемость накопительного ** и сочетания с технологией ** AI ** постепенно принесет пользу будущему развитию абстракции аккаунта. **

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

• **В настоящее время **Layer2 ** не имеет производительности (с точки зрения задержки и пропускной способности), ни подобной ** Solana **, ни ** Near ** Такой производительность сегментирования и отсутствие производительности параллельного выполнения, как у ** Sui ** и ** Aptos **, обновление Cancun улучшило лидирующие позиции Ethereum как лидера; **
• После обновления в Канкуне предполагается несколько основных сроков разработки Полностью Danksharding** (2~5 лет), *MEV * и ** PBS лендинг (1~3 лет), абстракция аккаунта (1~2 лет), ***ЗК * * *Все (3~6 лет), EOF и опыт разработки (сколько раз вы видели расширение?). **

** Плеть**

• Цель: сосредоточиться на решении проблем с MEV.
• Решение: сведите к минимуму MEV на прикладном уровне с помощью «разделения предложений и разработчиков» (PBS). В настоящее время можно оптимизировать большие двоичные объекты и ввести службы предварительного подтверждения или средства защиты от упреждения.
• PBS — это разделение производителей блоков и сортировщиков. Сортировщик отвечает только за сортировку вне зависимости от цепочки, а создатель блока не заботится о транзакции, а напрямую выбирает пакет, сделанный сортировщиком, и помещает его в цепочку. Этот процесс сделает весь процесс более справедливым и облегчит проблемы с MEV, что и является идеей экстернализации MEV.
• Степень завершенности ПБС еще очень низкая, а более зрелые - Сотрудничество с внешними решениями MEV - mevboost от flashbots.
• Расширенная версия "Enshrined Разделение «предлагающий-строитель» (ePBS)» имеет более низкую степень завершенности и более длительный цикл, и предполагается, что оно не будет реализовано в краткосрочной перспективе. Существуют также прогрессивные версии PEPC и Optimistic. Ретрансляция, повышающая гибкость и адаптивность платформы PBS.

** Грань**

• Цель: использовать дерево Verkel для замены Merkle, внедрить решение для минимизации доверия, позволить легким узлам получить такую же безопасность, как и полные узлы, и сделать проверку блоков максимально простой и легкой.
• При этом в дорожную карту Verge явно добавляется ZKизация L1.ZK будет общей тенденцией будущего расширения и ускорения;
• Решение: внедрить zk-SNARK для замены старой системы подтверждения, включая облегченные клиенты на основе SNARK; SNARK для изменения состояния консенсуса; Enshrined Роллапы。
• Деревья Веркла являются более эффективной альтернативой деревьям Меркла для конкретных состояний, которым не нужно предоставлять путь от каждого сестринского узла (узлов, имеющих одного и того же родителя) к выбранному узлу, а только сам путь в качестве доказательства. Часть Веркла доказательства в 3 раза эффективнее, чем доказательства Меркла.
• Закреплено Rollup относится к Rollup, который имеет какую-то согласованную интеграцию на L1. Преимущество состоит в том, что он наследует консенсус L1 и не требует токенов управления для выполнения обновлений rollup. В то же время, выполняя вычисления вне цепочки и публикуя только результаты в блокчейн, это может увеличить количество транзакций, но техническая сложность реализации относительно велика. Комбинация этих объединений в будущем сможет удовлетворить большинство потребностей экосистемы блокчейна в ближайшие несколько десятилетий.

** удалять**

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

• Состояние покоя. Когда дело доходит до обработки роста состояния, есть две основные цели: слабое безгражданство, которое относится к цели использования состояния только для создания блока, но не для его проверки; состояние, к которому осуществляется доступ. Состояние гибернации должно уменьшить состояние, которое узел должен хранить, в общей сложности на 20-50 ГБ。
• На пятом этапе Purge, EIP 4444 явно прописан в Roadmap, EIP-4444 требует, чтобы клиент очищал данные старше одного года, и на этом этапе еще есть некоторые работы по оптимизации EVM, такие как упрощение механизма прекомпиляции GAS и EVM и т.д.;

** Разориться**

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

Справочные материалы:

• Обновление встречи разработчиков ядра Ethereum:
• Эфириум Все основные разработчики звонят по номеру 148 Записать
• Эфириум Все основные разработчики звонят № 149, рецензия
• Эфириум Вызов уровня консенсуса № 99 Записать
• Эфириум Все основные разработчики звонят по номеру 150 Записать
• Эфириум Звонок всем основным разработчикам #151 Записать
• Эфириум Вызов уровня консенсуса № 100 Записать
• Эфириум Обращение всех основных разработчиков № 152 Записать
• Эфириум Обращение всех основных разработчиков № 153 Записать
• Эфириум Обсуждение форума Original Magicians:
• Эфириум Обращение всех основных разработчиков № 156 Записать
• Эфириум Обращение всех основных разработчиков № 157 Записать
• Эфириум Обращение всех основных разработчиков № 158 Записать
• Эфириум Обращение всех основных разработчиков № 159 Записать
• Эфириум Обращение всех основных разработчиков № 160 Записать
• Эфириум Консенсус для всех основных разработчиков №108 Записать
• Эфириум Обращение всех основных разработчиков № 161 Записать
• Эфириум Консенсус для всех основных разработчиков №109 Записать
• Эфириум Обращение всех основных разработчиков № 162 Записать
• Эфириум Консенсус для всех основных разработчиков №110 Записать *Тим написал в Твиттере о последнем обновлении Ethereum Cancun (09.06.23):
• Консенсус разработчиков Ethereum для всех основных разработчиков #111 Записать
• Эфириум Консенсус для всех основных разработчиков №112 Записать
• Содержимое, связанное с обновлением Ethereum:
• Введение в код самоуничтожения:
• Ознакомьтесь с предложением EVMMAX и BLS12-381.
• Помимо EIP-4844, что еще будет включать обновление Cancun? Взгляд на последний консенсусный вызов Ethereum
• Какой новый контент был добавлен в обновлении Ethereum Shanghai?
• твиты:
• ХОРОШО Венчурные предприятия: после обновления Ethereum Shanghai Канкун расширяет потенциальные инвестиционные возможности. Форсайт Новости
• В дополнение к высококлассному EIP-4844, какие предложения будут включены в обновление Cancun?
• V God: функцию EVM стоит рассмотреть для удаления
• Прото-данкшардинг Часто задаваемые вопросы
• Рекомендовано V God 丨 Для глубокого понимания дорожной карты шардинга Ethereum достаточно прочесть этот отчет.
• Статья для понимания Danksharding, нового плана обновления Ethereum.
• Расшифруйте интересные факты и скрытые секреты в последней дорожной карте Ethereum
• Виталик: Почему SELFDESTRUCT приносит больше вреда, чем пользы для экологии Ethereum
• Видение Эфириума:
• Блокворс Научный сотрудник Бррр: Как Proto-Danksharding ускоряет L1 Ethereum Масштабируемость объединения
• 111-е собрание Ethereum ACDC: обсуждение окончательного объема обновления Deneb и трех предложений, включая EIP-7044.
• КОЛ Взгляд Стейси Муур на эволюцию решений для масштабирования Ethereum: OP Стек、Произвольный Орбита、Полигон 2.0
• Горизонтальное сравнение трех типов роллапов: классические роллапы (оптимистический/ZK Роллапы）、Закреплены Роллапы、Соверен Роллапы
• [AMA] Мы — EF Research (часть 8: 07 июля, 2022):
• 3 популярных трека, которые стоит переосмыслить в 2023 году
• Черногория EDCON Мысли на конец 2023 года: взгляд на инфраструктуру и тенденции приложений
• Бесконечная фантазия о возможности совмещения AI и Web3
• AI+Web3: Изучение интеграции искусственного интеллекта и блокчейна.
• Сравнение zk-rollup и op-rollup: анализ почему текущий zkSync из метода проверки Плата за газ высокая
• «Добавление томов к томам»: решения для абстрагирования учетных записей в эпоху объединения
• Углубленная интерпретация ZKML: технические принципы, сценарии применения, преимущества и проблемы
• ZKML: технология развертывания модели, которая объединяет AI и блокчейн для обеспечения защиты конфиденциальности.
• способный данные безопасности шардинг
• Диалог с Ци, основателем EthStorage Чжоу | Доступность данных и децентрализованное хранилище
• Прочтите последнюю версию дорожной карты развития Ethereum в одной статье
• О космосе и Краткое введение во время
• Оригинальное предложение:
• ОИП 4844：
• ОИП 6780：
• ОИП 1153：
• ОИП 5920：
• ОИП 5656：
• ОИП 7069：
• ОИП 4788：
• ОИП 2537：
• ЭВММАКС EIP：
• ОИП 6601：
• ОИП 6990：
• EOF изменения:
• ОИП 663：
• ОИП 3540：
• ОИП 3670：
• ОИП 4200：
• ОИП 4750：
• ОИП 5450：
• ОИП 6475：
• ОИП 6493：
• пиар 3175：