Посібник для початківців
Gate Post
Прямі трансляції
Чат
Майбутні події
Новини
Блог Gate
Головна
Рекомендовані
Популярні
В полі зору
Публікація

Минуле, теперішнє та майбутнє оновлень Канкуна

金色财经_vip

Минуле життя

**Чому потрібне оновлення в Канкуні? **

  • Бачення Ethereum полягає в тому, щоб стати більш масштабованим і безпечнішим за умови децентралізації. Поточне оновлення 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 визначає верхню межу безпеки, що також є основним вмістом оновлення в Канкуні.
  • Ітераційний маршрут екології Ethereum не може підвищити продуктивність еталонного тесту Solana (щодо затримки та пропускної здатності), а продуктивність фрагментації Near не буде спостерігатися в короткостроковій перспективі, а також продуктивність паралельного виконання Sui та Aptos. У короткостроковій перспективі Ethereum може створити лише багатошарову структуру з Rollup як ядром, тому Cancun оновлюється, щоб вирішити TPS, газ Комісії та досвід розробника мають вирішальне значення для дорожньої карти Ethereum.

**Як планується дорожня карта Ethereum? **

  • Кілька останніх важливих оновлень і їхні цілі *

  • 2020рік12місяць1* Ланцюжок Beacon офіційно випущено, прокладаючи шлях для оновлення POS*

  • 2021**8місяць5** Лондонське оновлення, EIP1559 змінює економічну модель Ethereum;

  • 2022рік9місяць15* Паризьке оновлення (The Злиття), завершено POW перемикання POS;*

  • 2023рік4місяць12* Оновлено в Шанхаї, вирішено проблему зняття застави;*

  • Оновлення, пов’язані з економічною моделлю та POS, завершено, і кілька наступних оновлень вирішили проблеми продуктивності Ethereum, TPS і досвіду розробників;

  • Наступним кроком є зосередження на дорожній карті Ethereum The Сплеск 。

  • Ціль: Отримайте 100 000+ TPS у зведеному режимі.

  • Є схеми 2, у ланцюзі та поза ланцюгом:

  • Рішення поза мережею: відноситься до рівня 2, включаючи зведення тощо.

  • On-chain схема: відноситься до внесення змін безпосередньо в L1, яка є популярною схемою шардингу. Просте розуміння шардингу полягає в тому, щоб розділити всі вузли на різні області та виконати завдання кожної області, що ефективно збільшить швидкість;

  • Аналіз схеми шардингу:

  • Дилема схеми сегментування: раніше шардинг включав сегментування стану, сегментування транзакцій тощо, але синхронізація між різними шардами є проблемою. Зараз важко завершити синхронізацію даних великомасштабного вузла мережі. , не тільки не може вирішити ситуацію з MEV, але також може знадобитися велика кількість виправлень, щоб компенсувати різні проблеми, які можуть виникнути, і які неможливо реалізувати в короткостроковій перспективі.

  • Danksharding — це новий дизайн сегментування, запропонований для Ethereum, Його основною ідеєю є Централізоване виробництво блоків + Децентралізована перевірка + **Стійкість до цензури,**Це також пов’язано з доступністю даних, згаданою нижче. Вибірка (DAS), Розділення виробника-пакувальника блоків (PBS) і список стійкості до цензури (Crlist). Найбільше значення основної ідеї Danksharding полягає в перетворенні Ethereum L1 на єдину систему розрахунків (settlement) і доступність даних (Data availability) Наявність）层。

*Схема шардингу поділена на 2 кроки, наразі вона розділена на Прото- шардинг та Повне зведення. ***

  • Тому- danksharding**：**
  • представити: Допоможіть зменшити комісію L2 і збільшити пропускну здатність, ввівши blobs , водночас як рішення перед шардингом, щоб прокласти шлях до повного шардингу. Очікується, що після прото-danksharding впровадження danksharing займе 2-5 років.
  • Вміст: головною особливістю прото-danksharding є запровадження нового типу blob-транзакцій. Blob має характеристики великої ємності та низької вартості. Додавання таких пакетів даних до Ethereum може дозволити зберігати всі зведені дані в blob, значно зменшуючи навантаження на головний ланцюг.Тиск зберігання також може зменшити вартість згортання.
  • Повне зведення
  • Вступ: зведений пакет повністю розширено, зосереджуючись на використанні доступних даних.
  • зміст:
  • P2P-дизайн DAS: деякі роботи та дослідження, пов’язані з проблемами мережевого підключення до розподілу даних;
  • Клієнт вибірки доступності даних: розробіть полегшений клієнт, який може швидко визначати, чи доступні дані, шляхом випадкової вибірки кількох кілобайтів;
  • Ефективне самовідновлення DA: здатність ефективно відновлювати всі дані за найгірших умов мережі (наприклад, атаки зловмисного валідатора або тривалий простой вузлів великих блоків).

Зустріч розробників Ethereum Core

Кожне оновлення Ethereum залежить від основної зустрічі розробників, шляхом спільного обговорення основних учасників, і відповідно до ряду пропозицій від розробників визначається майбутній напрямок розвитку

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

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

Графік зустрічей, пов’язаних з ескалацією у Канкуні

**Відповідно до змісту обговорення, це оновлення в Канкуні можна приблизно розділити на 5 етапів. ***

Фаза 1 - Представлення тем оновлення

Представте нові завданняproto-danksharding*,EOF та «selfdestruct» * Opcode, поверхове обговорення вмісту оновлення Shanghai**

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

Етап 2 - Визначення термінів та підготовка до церемонії KZG

Наприкінці 2022** конференція Ethereum в основному зосереджується на ***EOF та EIP 4844 Обговорення, продовжуючи просувати EIP 4844 Попередня церемонія налаштування, необхідна для церемонії ***—*KZG, розробники будуть *******23 **** Рік **** 1 **** місяць офіційно підтверджено, яке оновлення **** 4844 **** з’явиться в ***

  • 22 листопада EOF або proto-danksharding було згадано під час телефонної конференції № 149 усіх основних розробників Ethereum. Наразі розробники все ще розглядають можливість розміщення його в оновленні в Шанхаї;
  • На зустрічі консенсусного рівня 2, 22 грудня, Трент, керівник екосистеми Ethereum Ван Еппс оновив EIP 4844 Прогрес у впровадженні необхідної церемонії довіреного налаштування для створення a Код безпеки використовується в 4844. Ван Еппс сподівається, що церемонія стане однією з найбільших за всю історію криптопростору, збираючи від 8 000 до 10 000 внесків, а період публічних внесків для церемонії триватиме близько 2 місяців і розпочнеться десь у грудні;
  • Під час основної зустрічі розробників того ж дня відбулася дискусія навколо EOF і деактивації коду операції самознищення. Розробник Ethereum Foundation заперечував проти перенесення EOF до Канкуна, стверджуючи, що якщо зміни коду не будуть включені в Шанхай, це Можливість потрапити в Канкун дуже мала, щодо коду самознищення, є розробники, які виступають за просування EIP на той час 4758, але вимикання цього коду операції напряму призведе до поломки деяких програм, і розробник вважає, що цей EIP слід ще раз зважити деякий час, перш ніж створювати крайовий випадок для захисту цього типу контракту;
  • На основній зустрічі розробників 9, 22 грудня було сприяно реалізації церемонії KZG щодо оновлення Канкуна та поточного EIP 4844 Необхідна церемонія довіреного встановлення готова;
  • На нараді рівня консенсусу 16, 22 грудня щодо EIP 4844, розробники обговорили об’єднання двох різних запитів на вилучення (PR) у специфікацію для прото-danksharding, один пов’язаний з тим, як вузли обробляють доступність даних після певного моменту після скорочення даних, а інший, коли блок Нові коди помилок будуть представлені для попередження вузли, коли інформація про blobs відсутня
  • Під час основної наради розробників 5 січня 23 року розробники досягли консенсусу щодо видалення модифікацій коду, пов’язаних із реалізацією EOF, з оновлення в Шанхаї. У цей час Бейко запропонував вирішити через два тижні, чи слід включати EOF в оновлення Cancun;

Фаза III - Попереднє обговорення обсягу пропозиції

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

  • На основній нараді розробників 20 січня 23 року EOF було перенесено до Канкуна для оновлення;
  • На основній нараді розробників 6 березня 23 року попередня пропозиція щодо оновлення в Канкуні була такою: EIP 4788 (корінь стану загальнодоступного ланцюга маяків), EIP 2537 (Ефективне виконання таких операцій, як перевірка підпису BLS і перевірка SNARK), EIP-5920 (представляє новий код операції PAY) і EIP Комбінована реалізація 6189 (для забезпечення сумісності SELFDESTRUCT з деревами Verkle) і EIP-6190 (зміна функції SELFDESTRUCT, щоб викликати лише обмежену кількість змін стану);
  • На основній зустрічі розробників 16 і 23 березня, за винятком EOF і EIP 4844, такі пропозиції були розглянуті для включення в Канкун: формат SSZ, видалення SELFDESTRUCT, EIP 2537、EVMMAX、EIP
  1. Необмежена кількість інструкцій SWAP і DUP, введення кодів PAY і коренів стану маяка в EVM;
  • На основній зустрічі розробників 30 березня 23 року вперше було висунуто пропозицію EIP-6780 щодо вимкнення SELFDESTRUCT, яка також є пропозицією щодо вимкнення SELFDESTRUCT, яку Канкун нарешті вирішив використати. Але щодо реалізації EOF, від Erigon (EL) Розробник із команди клієнта сказав EOF «Занадто багато змін», щоб конкурувати з пропозицією щодо покращення Ethereum EIP у майбутньому оновленні в Канкуні 4844, була пропозиція реалізувати EOF у хардфорку незабаром після оновлення в Канкуні;

Четвертий етап - визначити чіткий напрямок оновлення пропозиції та видалити нерелевантні пропозиції

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

  • 23****4місяць12****, оновлення Ethereum Shanghai завершено;
  • Під час основної зустрічі розробників 13.04.23 розробники обговорили EIP 4844 (для надання даних про корінь стану CL в EL), для оновлення розглядається принаймні дев’ять інших EIP, а саме EIP 4844**, САМОЗНИЩЕННЯ ВИДАЛИТИ (EIP-6780, EIP 4758、EIP 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIP (EIP 6601 та EIP 6690), SS зміни (EIP 6475、EIP 6493、EIP 6465、EIP 6404 та EIP 6466 ）、EIP 5656 та **EIP 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* subset) було видалено з оновлення в Канкуні. **EOF Оновлення було перенесено з Шанхаю на конференції розробників Ethereum на початку ****2023****1**** року, а згодом було оновлено з * *** З кінця 1 до початку 4 у 23****, він з’являтиметься в оновленні Cancun за замовчуванням, але в ** 23** **EOF **знову видалено на зустрічі розробників 29, 4. **

П'ятий етап - остаточне визначення пропозиції та доопрацювання деталей

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

  • Консенсусна зустріч Ethereum Core 5/5/23, обговорюючи останній згаданий EIP 4788, додаючи EIP 6987 та EIP Обговорення в 6475, ці дві пропозиції стосуються верифікаторів і транзакцій SSZ відповідно;
  • На 161-й зустрічі виконавчого рівня Ethereum 11, 23 травня Тім Бейко сказав, що обсяг оновлення Cancun все ще можна змінити протягом наступних кількох тижнів, але без чітких порад розробників обсяг оновлення Cancun залишиться в стані «за замовчуванням», і обговорення EIP-4844 показує що розробка Автор погодився видалити SSZ з реалізації EL EIP-4844, **але це ще не вплинуло на подальший прогрес ** 6475 **. **На додаток до цього, розробники також коротко обговорили два EIP для розгляду в Канкуні, а саме EIP 6969（EIP
  1. та EIP 5656 (ефективні інструкції EVM для копіювання областей пам'яті);
  • Розробки в 4844 були коротко обговорені на нараді Developer Consensus 18-травня-23, як-от дозвіл додаткам смарт-контрактів на EL перевіряти докази стану CL;
  • Деактивація SELFDESTRUCT, зміни специфікації EIP-4844, керування кодом операції та потенційні остаточні доповнення Cancun обговорювалися на 162-й зустрічі Ethereum Core 25 травня 2023 року. Тим Beiko рекомендує обмежити майбутні розмови щодо розширення охоплення Канкуна такими п’ятьма EIP: EIP-5920**, 5656, 7069,* ** 4788* ** і ** 2530**. Розробники підтвердять протягом наступних кількох тижнів ** Dencun** (****Deneb
  • весь асортимент Cancun****);**
  • На 110-й зустрічі рівнів консенсусу Ethereum 1 червня 2023 року дослідник з Ethereum Foundation представив результати експерименту з даними щодо здатності вузлів основної мережі Ethereum поширювати великі обсяги даних. З цього результату дослідник припустив, що EIP Специфікація 4844 зросла з максимум 4 blobs до 6 на блок. Водночас розробники розглядають ЕІП 4788 включено в оновлення Cancun;
  • На основній зустрічі розробників 13 червня 2023 року розробники офіційно підтвердили обсяг оновлення, включаючи EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 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, максимальний ліміт blob збільшено з 4 до 6 і 4844 тестових мереж Devnet #7 скоро.

це життя

  • Основним вмістом є EIP 4844，即Proto-Danksharding
  • Остаточний діапазон EIP для цього оновлення в Канкуні: EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788. Тим часом на 111-й зустрічі Ethereum ACDC 19 червня розробники продовжили обговорення EIP 6988、** EIP 7044**、**EIP 7045 для включення в Deneb. Розробники заявили, що планують об’єднати три вищезазначені EIP у специфікацію Deneb найближчими тижнями.

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

EIP 4844

  • Вступ:
  • Назва пропозиції EIP4844 — Proto-Danksharding, що є попереднім протоколом повної версії розширення шардингу Danksharding.Весь набір схем шардингу насправді обертається навколо Rollup для розширення в мережі. **Мета програми — розширити ** 2 рівень **Зведення——****Допомагаючи L2 зменшити комісію та збільшити пропускну здатність , прокладаючи шлях для повного шардингу (шардинг). **
  • Під час телефонної конференції 23 лютого розробники Ethereum будуть EIP Оновлення 4844 називається Денеб, що є назвою зірки першої величини в сузір’ї Лебедя, яка є EIP у відповідній версії GitHub у майбутньому Назву 4844 буде змінено на Deneb; на зустрічі 1, 23 червня буде внесено деякі зміни в наступну специфікацію оновлення Ethereum, яка називається Deneb на стороні CL і Cancun на стороні EL;
  • На зустрічі розробників 23, 23 червня розробники підготувалися до оновлення EIP Попередньо скомпільована адреса 4844. Наразі основні розробники додали 9 попередніх компіляцій до EVM і активують EIP до 4844 і 4788 створюють дві прекомпіляції за адресами "0xA" і "0xB" відповідно. На консенсусній зустрічі 29 червня EIP готовий до запуску Спеціальна короткострокова тестова мережа Devnet 4844 #7.
  • EIP-4844** представляє абсолютно новий тип транзакції - Blob Транскація。** *Профіль Blob:
  • Blob, схожий на пакет даних плагіна, лише 128 на початку Обсяг пам’яті KB, на початку обговорення пропозиції, цільовий і ліміт Blob становив 2/4, і його було скориговано до 3/6 на зустрічі розробників 9 червня 23. Тобто наразі кожна транзакція в Ethereum може містити до трьох Blob-транзакцій, тобто 384 KB, мета кожного блоку Ємність Blob становить 6, тобто 768 KB, який може містити до 16 blob-об’єктів, що становить 2 МБ;
  • Це може мати певний вплив на стабільність мережі, але команда розробників Ethereum все ж вирішила спочатку протестувати, щоб уникнути необхідності подальших хардфорків для розширення блоку blob.
  • Кляпка **в ** KZG 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 полягає в тому, щоб завантажити свій сертифікат зберігання Layer2, і його вартість DA може бути зменшена до 5% від оригіналу;
  • Topia розраховує зменшити вартість у 100~1000 разів, тому що Danksharding основної мережі також має враховувати безпеку та сумісність із мережевим мовленням рівня 1 P2P.
  • **DA****Рішення: Danksharding (рішення шардингу для розширення Ethereum) наразі, якщо розширення продовжуватиметься, навантаження на вузол може бути занадто великим (****16 Мб). **** вище) і недостатня доступність даних (30 днів дії). Рішення: **
  • Вибірка доступності даних (Data Availability Sampling) - зменшує навантаження на вузли
  • Розділіть дані в Blob-об’єкті на фрагменти даних і дозвольте вузлу перейти від завантаження Blob-даних до випадкової перевірки фрагментів Blob-даних, щоб фрагменти Blob-даних були розкидані по кожному вузлу Ethereum, але повні Blob-дані є зберігається в усьому. У реєстрі Ethereum передумовою є те, що вузли мають бути достатніми та децентралізованими;
  • DAS використовує дві технології: код стирання (Erasure Кодування) і поліноміальне зобов’язання KZG (KZG зобов'язання；;
  • Proposer-Packager Separation (PBS) — вирішено проблему розподілу праці між вузлами, вузли з конфігурацією високої продуктивності відповідають за завантаження всіх даних для розподілу кодування, а вузли з конфігурацією низької продуктивності — за вибіркова перевірка.
  • Вузол із конфігурацією високої продуктивності може стати побудовником. Побудовнику потрібно лише завантажити дані blob для кодування та створити блок (Block), а потім передати його іншим вузлам для вибіркової перевірки. Для побудовника, оскільки синхронізація вимоги до обсягу даних і пропускної здатності високі, тому він буде відносно централізованим;
  • Вузол із конфігурацією низької продуктивності може стати пропонентом (Proposer), і пропоненту потрібно лише перевірити достовірність даних і створити та передати заголовок блоку (Block Header), але для пропонента (Proposer) вимоги до обсягу даних синхронізації та пропускної здатності низькі, тому він буде децентралізованим.
  • Антицензурний список (crList) — вирішує проблему, пов’язану з тим, що пакетувальники можуть навмисно ігнорувати певні транзакції та випадковим чином сортувати та вставляти транзакції, які вони хочуть отримати, щоб отримати MEV, через їхню надмірну можливість перегляду.
  • Перш ніж розробник (Builder) запакує блокові транзакції, пропонент (Proposer) спочатку опублікує стійкий до перегляду список (crList), який містить усі транзакції в mempool;
  • Розробник (Builder) може вибрати лише упаковку та сортування транзакцій у crList, що означає, що розробник не може вставити власну приватну транзакцію для отримання MEV, а також він не може навмисно відхилити транзакцію (крім випадків, коли Gas ліміт повний);
  • Після упаковки Builder транслює остаточну версію хешу списку транзакцій Пропоненту, а Пропонент вибирає один зі списків транзакцій для створення заголовка блоку (Блок Заголовок) і трансляція;
  • Коли вузол синхронізує дані, він отримає заголовок блоку від пропонента (Proposer), а потім отримає тіло блоку від пакувальника (Builder), щоб переконатися, що тіло блоку є остаточно вибраною версією.
  • Двослотова PBS - вирішує проблему, пов’язану з тим, що централізовані пакувальники стають все більш централізованими завдяки придбанню MEV
  • Використовуйте режим ставок для визначення блоку:
  • Конструктор (Builder) створює заголовок блоку списку транзакцій після отримання crList і ставок;
  • Пропонент (Proposer) вибирає заголовок блоку та конструктор (Builder), які нарешті зробили успішну ставку, і пропонент безумовно отримує комісію за виграшну ставку (незалежно від того, чи згенеровано дійсний блок);
  • Верифікаційна комісія (Комітети) підтверджує переможний заголовок блоку;
  • Будівельник розкриває тіло виграшного блоку;
  • Верифікаційна комісія (Комітети) затверджує тіло блоку-переможця та проводить перевірочне голосування (якщо блок пройдено, блок буде виготовлено, якщо пакувальник навмисно не надасть блоку Body, буде вважатися, що блок не існує).
  • Значення:
  • По-перше, конструктор (Builder) має більше повноважень для пакетування транзакцій, але crList, згаданий вище, по-перше, обмежує можливість тимчасового вставлення транзакцій, а по-друге, якщо конструктор (Builder) хоче отримати прибуток, змінюючи порядок транзакцій, тоді йому потрібно сплатити багато витрат на тендер на початку, щоб переконатися, що він може отримати кваліфікацію керівника блоку, тоді прибуток MEV, який він отримує, буде ще більше зменшено, і в цілому це матиме вплив на засоби та фактичну вартість отримання МЕВ;
  • Однак на ранній стадії лише невелика кількість людей може стати пакувальниками (враховуючи проблеми з продуктивністю вузла), тоді як більшість людей стають лише пропонентами, що може призвести до подальшої централізації. У той же час кількість пакувальників дуже мала У випадку , деякі досвідчені майнери з можливостями MEV матимуть більше шансів зробити успішну ставку, що більше вплине на фактичний ефект рішення MEV;
  • Має певний вплив на деякі рішення MEV, які використовують аукціони MEV.
  • Значення:
  • EIP 4844 Насправді надзвичайно спрощена версія Danksharding**: **Він забезпечує той самий інтерфейс програми, що й Danksharding, включаючи новий код операції під назвою Data Хеш; і новий об’єкт даних під назвою Binary Великі об'єкти, тобто Blob;
  • proto-danksharding ** використовується для реалізації повної ** Danksharding ** специфікації "брекет"** (** це формат транзакції та правила перевірки****) * * Пропозиція: однак шардинг ще не реалізовано, і всі верифікатори та користувачі все ще повинні безпосередньо перевіряти наявність повних даних;
  • Чому довгострокова перспектива обирає прото-danksharding не EIP 4488 ** безпосередньо зменшує плату за ** layer2 **, тому що під час оновлення до повного сегмента в майбутньому потрібно лише невелике коригування:
  • EIP Основна практична відмінність між 4488 і proto-danksharding полягає в тому, що EIP-4488 намагається мінімізувати зміни, які Ethereum має зробити сьогодні, тоді як proto-danksharding вносить більше змін в Ethereum сьогодні, щоб оновити до Ethereum у майбутньому. необхідний для шардингу повної версії;
  • Незважаючи на те, що досягти повного сегментування (із вибіркою доступності даних тощо) дуже складне завдання, і після впровадження прото-danksharding ще потрібно виконати багато роботи, ці складності будуть контролюватись на рівні консенсусу. Після розгортання прото-danksharding команді клієнта рівня виконання, розробникам зведення та користувачам не потрібно виконувати жодної додаткової роботи, щоб перейти до повного шардингу.
  • Для досягнення повного сегментування необхідно завершити фактичну реалізацію ** PBS, підтвердження делегування та вибірку доступності даних, але такі зміни будуть зосереджені в ** CL * * рівень, розробникам не потрібно змінювати **: 4844 наразі реалізує новий тип транзакції, який точно такий самий, як формат транзакції, логіка перехресної перевірки консенсусу та логіка рівня виконання, необхідні для повного шарду, а також отримані для blobs , незалежного ціноутворення на газ, що самоналаштовується, щоб досягти повного сегментування в майбутньому, необхідно завершити фактичну реалізацію PBS, підтвердження делегування та вибірку доступності даних, але ці зміни лише на рівні CL, і не вимагають модифікації від розробників рівня EL або зведення, що зручно для розробки.

за яким слідуєСАМОЗНИЩЕННЯ видалення***,EIP-6780 було остаточно визначено як найбільш прийнятне рішення, але розробник на 26** в зустріч tim** запропонував додати ще один код операції до цієї пропозиціїSETCODE, щоб програмні облікові записи все ще оновлювалися*

САМОЗНИЩЕННЯ видалення EIP-6780**：**X

  • фон:
  • 21 березня Віталік припустив, що SELFDESTRUCT приносить більше шкоди, ніж користі для екології Ethereum Основна причина полягає в тому, що він єдиний, який може змінювати нескінченну кількість об’єктів стану в одному блоці, що призводить до змін кодів контрактів, і може використовуватися без згоди облікового запису. може змінювати код операції балансу облікового запису, що має великі приховані небезпеки для безпеки Ethereum;**
  • Єдиний спосіб видалити контракт у ланцюжку - це САМОЗНИЩЕННЯ. Якщо ви викликаєте функцію самознищення в контракті, ви можете самознищити контракт. Ethereum, що зберігається в контракті, буде надіслано на вказану адресу. Решту коду та змінних зберігання буде видалено в кінцевому автоматі. Насправді дія розірвання контракту звучить добре в теорії, але насправді вона дуже небезпечна. Хоча функція selfdestruct** може допомогти розробникам видалити смарт-контракт і перевести залишок у контракті на вказану адресу в екстрених випадках, ця функція також використовується злочинцями, що робить її засобом атаки. **
  • На основній нараді розробників 13, 23 квітня для участі в обговоренні було представлено чотири пропозиції щодо SELFDESTRUCT, а саме 6780, 4758, 6046 і 6190, а також подальший EIP 6780 було встановлено як остаточну пропозицію.
  • Вступ: selfdestruct — це екстрена кнопка смарт-контракту, яка руйнує контракт і переказує залишки ETH на призначений рахунок.
  • EIP 6780: Вимкнути SELFDESTRUCT, якщо вони не знаходяться в одній транзакції в контракті.
  • ОНОВЛЕННЯ: 26 травня Тім запропонував окрім видалення SELFDESTRUCT додати ще один код операції – SETCODE, щоб програмні облікові записи все ще оновлювалися. (тобто додається функція оновлення, а властивість в смарт-контракті оновлюється за допомогою update/upgrade), тут відбувається поглинання EIP Переваги 4758, які можуть дати простір для оновлення dapp.

  • Причина: маніпулювання кодом SELFDESTRUCT спочатку вимагало серйозних змін у стані облікового запису, наприклад видалення всіх кодів і сховища. Це створює труднощі для використання дерев Verkle у майбутньому: кожен обліковий запис зберігатиметься в багатьох різних ключах облікового запису, які не будуть явно пов’язані з кореневим обліковим записом.
  • ЗМІНЕНО: цей EIP реалізує зміни для видалення SELFDESTRUCT, за винятком наступних двох випадків
  • Додатки, які використовуються лише для САМОЗНИЩЕННЯ для виведення коштів, все одно працюватимуть;
  • SELFDESTRUCT, який використовується в тій самій транзакції в контракті, не потрібно змінювати.
  • Значення: Підвищена безпека
  • Раніше в основній мережі існував контракт, який використовував SELFDESTRUCT для обмеження того, хто може ініціювати транзакції через контракт;
  • Заборонити користувачам продовжувати вносити кошти та торгувати в сховищі після САМОЗНИЩЕННЯ, тоді це сховище може змусити будь-кого вкрасти токени в сховищі під час повторного використання.

Наведені нижче три пропозиції є пропозиціями щодо САМОЗНИЩЕННЯ, які згодом були видалені в 23році*****4 *** 6780 було офіційно обрано на основній нараді розробників *28, а інші три пропозиції було відхилено. Причина полягає в тому, що команда розробників Ethereum зрештою хоче повністю видалити код операції SELFDESTRUCT, а наступні три пропозиції в основному змінено шляхом заміни. ***

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

Слідує EIP 1153, економлячи газ, прокладаючи шлях для майбутнього дизайну сховищ

EIP 1153X

  • Коротко: тимчасові коди операцій для зберігання, додайте коди операцій для маніпулювання станом, який поводиться так само, як і зберігає, але скидається після кожної транзакції.
  • причина:
  • Запуск транзакції в Ethereum може генерувати кілька вкладених кадрів виконання, кожен кадр створюється інструкцією CALL (або подібною). Контракти можна повторно вводити в тій самій транзакції, у цьому випадку до одного контракту належить більше одного кадру.
  • Наразі ці кадри можуть обмінюватися даними двома способами: вводити/виводити через інструкції CALL і через оновлення магазину. Зв’язок через введення/виведення є небезпечним, якщо існує проміжна структура, що належить до іншого ненадійного контракту.
  • з повторним доступом lock як приклад, він не може покладатися на проміжні кадри для передачі даних про стан блокування: зв’язок SSTORE через сховище SLOAD є дорогим, а тимчасове сховище є спеціальним і ефективним рішенням проблеми міжкадрового зв’язку.
  • Змінено: до EVM додано два нові коди операції, TLOAD (0xb3) і TSTORE (0xb4).
  • Тимчасове сховище є приватним для контракту, якому воно належить, так само, як і постійне сховище, лише структура контракту-власника може отримати доступ до тимчасового сховища. Під час доступу до сховища всі кадри отримують доступ до того ж ефемерного сховища так само, як і до постійного сховища, але інакше, ніж до пам’яті.
  • Потенційні варіанти використання:
  • повторна вхідність замок；
  • Обчислювані в ланцюжку адреси CREATE2: параметри конструктора зчитуються з фабричного контракту, а не передаються як частина хешу коду ініціалізації;
  • Схвалення однієї транзакції EIP-20, наприклад #temporaryApprove(адреса витратник, сума uint256)；
  • Контракт комісії за переказ: сплачуйте комісію за контракт токена, щоб розблокувати перекази під час транзакцій;
  • Режим «до»: дозволяє користувачеві виконувати всі дії в рамках зворотного виклику та перевіряє, чи збалансовано «до» в кінці;
  • Метадані проксі-дзвінка: передавайте додаткові метадані для реалізації контрактів без використання даних виклику, наприклад значення незмінних параметрів конструктора проксі.
  • Значення:
  • Економте газ** за допомогою простіших** газових правил виставлення рахунків;
  • ** Вирішити проблему міжкадрового зв'язку; **
  • ** Не змінювати семантику існуючих операцій; **
  • Немає необхідності очищати резервуар після використання;
  • ** Майбутні проекти сховищ (наприклад, ** Verkle ** дерева) не потребують відшкодування за миттєве сховище. **

Після цього 4788, це може зменшити довіру до пулу застави**

EIP 4788**：**X

  • Вступ: корінь блоку маяка в EVM. *Оновлення: на зустрічі розробників 15, 23 червня розробники запропонували внести зміни в код, щоб покращити досвід стекера, цей EIP розкриє корінь блоку ланцюга маяків, який містить інформацію про стан внутрішнього ланцюга EVM, для розробки DApp. довіра автора мінімізує доступ.
  • ЗМІНЕНО: фіксуйте корені хешу кожного блоку ланцюга маяків у відповідному заголовку корисного навантаження виконання, зберігайте ці корені в контракті в стані виконання та додайте новий код операції для читання цього контракту.
  • Значення: Це пропозиція модифікації коду, яка пропонує модифікувати віртуальну машину Ethereum (EVM), щоб вона могла показувати стан контрактного рівня (CL). кореневі дані на рівні виконання (EL) можуть зробити зв’язок між різними протоколами та програмами в мережі Ethereum більш ефективним і безпечним**. **Дозвольте більш надійні конструкції для пулів стейкингу, протоколів перемикання та повторного ставлення.

*Останній —5656, який забезпечує ефективний новий код операції для копіювання пам’яті, але наразі його тимчасово включено в оновлення через його тестову пропускну здатність *

EIP 5656X

  • Вступ: MCOPY
  • Інструкція копіювання в пам'ять. Оновлення: 09.06.23, команда розробників заявила, що спочатку вони розділилися щодо MCOPY, оскільки, хоча це вирішило проблему безпеки, вони все ще були стурбовані тим, щоб додати його до пропускної здатності впровадження+тестування, необхідної для оновлення, але зрештою погодилися включити EIP , але буде розглянуто питання про видалення, якщо розробник зіткнеться з проблемами пропускної здатності під час тестування або на стороні клієнта. Таким чином, MCOPY* знаходиться в стані тимчасового включення в оновлення Cancun. **
  • Змінено: надана ефективна інструкція EVM для копіювання областей пам’яті.
  • Значення: копіювання пам’яті є базовою операцією, але її впровадження на EVM вимагає певних витрат.
  • Завдяки наявності інструкції MCOPY кодові слова та речення можна копіювати точніше, що збільшить продуктивність копіювання пам’яті приблизно на 10,5%, що дуже корисно для різних операцій з інтенсивними обчисленнями;
  • Це також буде корисно для компіляторів для створення більш ефективного та меншого байт-коду;
  • Це може заощадити певну кількість попередньо скомпільованих витрат на газ, але не може фактично сприяти реалізації цієї частини.

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

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

EIP 6988**:**X

  • Коротка інформація: запобігти обранню валідаторів із косою рискою як пропонентів блоків.
  • Важливість: посилення штрафів за порушення вузлів піде на користь ТГВ.

EIP 7044**:**X

  • Підсумок: забезпечення постійної дійсності підписаних виходів валідатора.
  • Значення: це може певною мірою покращити досвід стейкерів.

EIP 7045**:**X

  • Вступ: атестація волі Діапазон включення слота поширюється від рухомого вікна однієї епохи до двох епох.
  • Значення: підвищення безпеки мережі.

Видалити аналіз EIP

У **** день **************************************** ******************************************** В ** 160ACDE зустріч Ethereum, EVMMAX та **** EOF **** підтверджено, що його буде видалено з цього оновлення, зміни, пов’язані з EOF, можуть бути внесені в наступні щоденні оновлення***

EVMMAX EIP**:**

  • Коротко: EVMMAX прагне забезпечити більшу гнучкість арифметичних операцій і схем підпису в Ethereum. На даний момент є дві пропозиції EVMMAX, одна з EOF і одна без EOF.
  • EIP 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.
  • EIP 6690:
  • Зміна: EIP-6990 — це пропозиція, адаптована з EIP-6601 для впровадження оптимізованих модульних арифметичних операцій у EVM без використання EOF. У той час як для EIP-6601 потрібні EIP-4750 і EIP-3670 як залежності, EIP-6990 забезпечує більш незалежне рішення. Він забезпечує більш спрощений підхід, усуваючи залежність від EOF.
  • Значення: він зберігає основну функціональність EIP-6601, яка може виконувати оптимізовані модульні арифметичні операції з непарними модулями до 4096 біт. Це спрощення дозволяє ефективніше впроваджувати та приймати, водночас забезпечуючи переваги, пов’язані з перевагами EIP-6601.

EOF зміни**:**

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

5місяць26***************************** ************************************************* ************************************* 4844Зміна типу пов’язаної транзакції з SSZ на RLPозначає, що два а Канкуна SSZ EIP******, отжеEIPs 6475 та 6493** переміщено з Канкуна для оновлення***

EIP 6475X

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

EIP 6493X

  • Вступ: схема підпису транзакцій SSZ. Цей EIP визначає схему підпису для транзакцій із кодуванням простої серіалізації (SSZ) і вирішує, як вузли мають обробляти типи транзакцій blob, які відформатовані у форматі SSZ на CL, але закодовані інакше на EL. Цей EIP є частиною оновлення формату серіалізації Ethereum для міжрівневої узгодженості;
  • Фон: SSZ зміни
  • Вступ: простий SerialiZe — це метод серіалізації, який використовується в ланцюжку маяків.
  • СС Зміни також включають три інші допоміжні пропозиції, цього разу введено лише 6465.
  • EIP 6465: корінь вилучення SSZ, визначає існуючий Merkle-Patricia Перехід зобов’язань Trie (MPT) на зняття коштів із простої серіалізації (SSZ);
  • EIP 6404 / EIP 6466:
  • Обидва визначають існуючу Merkle-Patricia Проміси Trie (MPT) перебувають у процесі переходу на просту серіалізацію (SSZ).
  • EIP-6404 — Корінь транзакції SSZ
  • EIP-6466 — Основа отримання ССЗ

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

EIP 5920**:**X

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

EIP 7069X

  • Введення: змінена інструкція 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 Object Format (EOF) старі інструкції виклику можна буде відхилити в контракті EOF, гарантуючи, що вони значною мірою захищені від змін ціни на газ. Оскільки ці операції необхідні для усунення спостережуваності газу, EOF вимагатиме їх замість існуючих інструкцій;
  • Більш зручні коди повернення статусу: було введено зручні функції, які повертають більш детальні коди стану: успіх (0), відновлення (1), помилка (2), і їх можна розширити в майбутньому.

EIP 2537**:**X

  • Вступ: Попередня компіляція маніпуляції кривою BLS12-381.
  • Змінено: додано операції над кривою BLS12-381 як попередньо скомпільовану до набору, необхідного для ефективного виконання перевірки підпису BLS і перевірки SNARK тощо.
  • Значення: Ethereum може створювати більш безпечні криптографічні докази та покращувати взаємодію з ланцюгом маяків**. **

PR 3175 *** Згадано, але не включено до короткого списку, без подальшого обговорення ***

PR 3175**:**X

  • Коротко: ця пропозиція не дозволить покараним валідаторам пропонувати блоки після виключення з черги. Якщо більше 50% валідаторів будуть покарані за зловмисну поведінку, ці валідатори все одно зможуть пропонувати блокування, будучи примусово видаленими з мережі. За словами розробників, зміна цієї логіки є відносно незначною зміною рівня CL, яка забезпечує захист від «високих режимів відмови».
  • Відповідно до 108-ї консенсусної зустрічі розробників Ethereum Core 4 травня, PR 3175 перебуває в процесі форматування як EIP і буде змінено на EIP-6987, що з міркувань безпеки, щоб запобігти обранню посічених валідаторів як пропонентів блоків.

майбутнє

На підставі вищезазначеної інформації ми дійшли наступних висновків:

**1.**Основними цілями оновлення в Канкуні є, у порядку пріоритету, розширення потужності, безпека, економія газу та сумісність:

  • Немає сумніву, що розширення є першочерговим завданням (4844);
  • Безпека та економія газу на другому місці (6780, 1153, 5656 і 7045), при цьому враховуючи певний досвід розробника;
  • По-третє, це сумісність, така як оптимізація з’єднання, зв’язку та сумісності між прикладними програмами (4788, 7044 і 6988);
  • Очікувані дані: testnet 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 представляє blob даних як додатковий простір даних, унікальний для зведень, що значно зменшить витрати на зберігання, тим самим зменшуючи витрати на DA.
  • Фактичний час посадки довгий, а покращений ** TPS ** і зменшений ** газ ** все ще обмежені, тому це добре для ** DA * * проекти шарів у подальшій продовженій розробці:
  • iable про danksharding у polynya У статті про шардинг даних безпеки вказано, що впровадження займе 2-5 років;
  • ** Навіть якщо він приземлився, він може збільшити ** TPS ** і зменшити ** газ ** величини все ще обмежені:**
  • EIP 4844 наразі підтримує 6 блобів, і проблему майбутнього розширення можна вирішити лише за допомогою Danksharding;
  • Поточний блоковий простір Ethereum становить близько 200 KB. Після Danksharding запланований розмір у специфікації становить 32 мегабайти, що є приблизно 100-кратним покращенням. Наразі TPS Ethereum становить близько 15. В ідеалізованому стані він становитиме близько 1500 після збільшення в 100 разів, що не є великим покращенням величини.
  • Отже, потрібен довгий час для посадки + Обмежені фактичні зміни принесуть користь DA Проекти на рівні, наприклад Celestia, ** Eigenda** ** ** DA ** проект все ще може проходити дешевше та швидше ** TPS *, щоб конкурувати з ** Danksharding ** у майбутньому , ETHstorage Topia та інші нові проекти DA також можуть заповнити ринкову прогалину перед посадкою. **
  • Також необхідно вирішити такі технічні проблеми, як проблеми зі зберіганням і доступністю даних:
  • Є дві основні витрати на DA: одна — це вартість пропускної здатності мережі, інша — вартість зберігання, а сам 4844 не вирішує проблему зберігання та пропускну здатність ланцюжка блоків.
  • Blob зберігатиметься на консенсусному рівні Ethereum протягом приблизно 3 тижнів, а потім буде видалено. Якщо ви хочете зберігати повні історичні записи та зробити всі дані доступними, поточні рішення включають: сам dapp зберігає дані, пов’язані з ним, мережу порталу Ethereum (наразі розробляється) або протоколи сторонніх розробників, такі як дослідники блоків, історичні дані в BitTorrent або спонтанне зберігання окремими користувачами.
  • Таким чином, Proto-Danksharding отримає переваги протоколу зберігання, модульного протоколу та мережі розширення зберігання L1:
  • Попит на виклик історичних даних призведе до нового каналу розробки для протоколів децентралізованого зберігання або сторонніх протоколів індексування;
  • Подальші модульні угоди можуть виконувати транзакції через високошвидкісне зведення, рівень безпечного розрахунку відповідає за врегулювання, а недорогий рівень доступності даних з великою ємністю відповідає за гарантію;
  • Хороша мережа розширення сховища L1, наприклад Eth зберігання, яке може забезпечити рішення другого рівня для програмованого зберігання за нижчою вартістю зберігання.

**3.**Підвищення категорії в Канкуні: L2різноманітність, L3, RAAS і Доступність даних та інші треки

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

**4.**Оновлення в Канкуні покращує роботу розробників і користувачів

  • Канкун оновлює другу важливу пропозицію SELFDESTRUCT видалення ще більше покращить безпеку Ethereum.У той же час, для можливих проблем програмного оновлення облікового запису після видалення ми плануємо ввести новий код операції SETCODE, щоб покращити цю ситуацію;
  • Третя пропозиція EIP для оновлення в Канкуні 1153 додає код перехідної операції зберігання, який може, по-перше, заощадити газ, по-друге, вирішити проблему міжкадрового зв’язку та, нарешті, прокласти шлях для майбутнього дизайну сховища, наприклад дерева Verkle, якому не потрібно буде розглядати проблему відшкодування перехідних процесів. зберігання;
  • Четверта пропозиція EIP для оновлення в Канкуні 5656 представляє інструкцію копіювання пам’яті MCOPY, яка може точніше копіювати кодові слова та речення, що покращить продуктивність копіювання пам’яті приблизно на 10%;
  • П'ятою пропозицією щодо оновлення Канкуна є EIP 4788 може зробити зв’язок між різними протоколами та додатками в мережі Ethereum більш ефективним і безпечним, а також дозволить створювати надійніші проекти для пулів застав, протоколів мостів і повторних ставок;
  • Канкун оновлює останні (15, 23 червня) запропоновані оновлення EIP, орієнтовані на CL: EIP 6988、EIP 7044、EIP 7045, який покращує безпеку та зручність використання Ethereum у деталях, наприклад покращує досвід заставників і покращує безпеку мережі.
  • Серед видалених пропозицій SSZ-> Трансформація RLP створює два SSZ EIP（EIP 6475 та EIP
  1. було вилучено з оновлення в Канкуні; пропозиції, пов’язані з EOF, було видалено з оновлення в Канкуні після того, як їх було видалено з оновлення в Шанхаї, і наразі вважається, що це може бути безпосередньо реалізовано в наступному щоденному оновленні; EVMMAX пов’язано з деякими EIP пов’язані з підмножиною впровадження EOF, тому її також було переміщено з Канкуна для оновлення разом із EOF; враховуючи потенційні побічні ефекти, які можуть існувати під час передачі ETH, а також міркування, тестування та роботу з безпеки, необхідну для прийняття пропозиції , EIP 5920 видалено з оновлення.

**5. **Зв’язок із zkml і абстракція облікового запису

Малий вплив на zkml

  • ZKML є доказом нульового знання (Zero Знання) і машинне навчання (Machine Навчання); поєднання **блокчейну та ML моделі вирішує проблеми захисту конфіденційності та можливості перевірки машинного навчання:
  • Захист конфіденційності: конфіденційність вхідних даних, наприклад, використання великої кількості особистої інформації як даних для передачі в машину для навчання, конфіденційність особистої інформації є основною вимогою; або параметри моделі є основною конкурентоспроможністю проекту, і шифрування також потрібне для підтримки конкурентних бар'єрів. Коли існують подібні проблеми довіри, моделі ML не можуть отримати більш масштабні дані та програми.
  • Можливість перевірки: технологія підтвердження нульових знань має широкий спектр застосувань, а ZKP дозволяє користувачам знати правильність інформації без перевірки. І оскільки модель машинного навчання вимагає багато обчислень, модель ML може генерувати докази через ZK-SNARK, зменшуючи розмір доказів і зменшуючи вимоги до обчислювальної потужності ML.
  • Вимоги до зберігання ZKML ** мають мало спільного з ** DA **: **Потрібно щось на кшталт Space Основною технологією цієї окремої структури зберігання є новий протокол безпеки "SQL proof". Простіше кажучи, це сховище даних поруч із блокчейном, що дозволяє розробникам з’єднувати між собою та поза мережею в простому форматі SQL. завантажити результати безпосередньо в смарт-контракт;
  • ZK-SNARKs **є основною формою ** ZK ** у ** ZKML ** і може адаптуватися до розрахунку ** **ML у мережі ** ** З розвитком криптографії, особливо рекурсивний **SNARK доказ буде корисним ZKML Посадка в ланцюг:
  • ZK-SNARK характеризуються високою компактністю. Використання ZK-SNARK дає змогу верифікатору згенерувати короткий доказ, а верифікатору не потрібно взаємодіяти, йому потрібно лише виконати невелику кількість обчислень, щоб перевірити його достовірність. Цей тип доказу потрібен лише один раз. Природа взаємодії між верифікатором і верифікатором робить ZK-SNARK ефективними та практичними в практичних застосуваннях і більше підходить для вимог обчислювальної потужності ML у ланцюжку.
  • На даний момент неможливо навчатися в ланцюжку, і лише результати обчислень поза ланцюгом можуть зберігатися в ланцюжку:
  • Поточна проблема ML більше пов’язана з незадоволеними вимогами до обчислювальної потужності та низькою продуктивністю, спричиненою обмеженнями алгоритму (неможливо обчислити паралельно). Великі моделі ZK-доказів вимагають більшої обчислювальної потужності, яка не підтримується в ланцюжку. Поточні популярні ZK-SNARK підтримують лише доказ нульового знання ML з невеликим масштабом і малим обсягом обчислень, тобто обмеження обчислювальної потужності є ключовим фактором, що впливає на розробку додатків блокчейну ZKML, і ланцюжок може зберігати лише результати поза ланцюгові обчислення.

Хороша абстракція облікового запису

  • По-перше, оновлення в Канкуні може певною мірою зменшити ZK зведення Доказ оплати:
  • Поточна комісія за транзакцію zkSync залежить від 3 аспектів:
  • Вартість фіксованих ресурсів, споживаних верифікатором для створення доказів SNARK і їх перевірки, відносно висока;
  • Комісія за газ, коли верифікатор надсилає підтвердження SNARK до основної мережі Ethereum, ця частина комісії буде відповідно збільшена через перевантаження основної мережі;
  • Комісія за послуги, сплачена користувачем верифікатору, включаючи підтвердження транзакції, трансляцію повідомлень тощо.
  • Таким чином, якщо буде введено 4844, проблема збільшення плати за газ, спричинена перевантаженням магістральної мережі, буде пом’якшена, а вартість доказів ЗКП може бути певною мірою зменшена. Хоча це небагато порівняно з вартістю генерації доказів, враховуючи, що ZK все ще знаходиться на ранніх стадіях, не можна недооцінювати майбутню тенденцію розвитку серії ZK.
  • По-друге, абстракція облікового запису перетворює традиційні ** tx ** транзакції в ** useroperation, а потім ** useroperations use ECDSA * * Упаковане в блоки сховище в ланцюжку займає більше, ніж раніше, тому вимоги до сховища вищі;
  • **Далі, абстракція облікового запису і ** ZK rollup можуть доповнювати один одного:
  • Актуальною проблемою абстракції рахунків є газ Комісія дорога, тому що кроків занадто багато, і задіяні розумні контракти, тому є багато даних, які призводять до Gas Комісія дорога, а ЗК Перевага Rollup полягає в тому, що він може зменшити дані;
  • Абстракція облікового запису ускладнює гарантування безпеки: оскільки АА передбачає кілька контрактів, безпека є проблемою, але після поступового формування L2 у майбутньому рівень консенсусу не буде змінено, смарт-контракти матимуть більше застосувань, а безпека Абстрагування рахунку також можна гарантувати, за допомогою ЗК Довірена перевірка зведення ще більше покращить безпеку.
  • **Нарешті, враховуючи розвиток технології ** AI , це може допомогти підвищити безпеку онлайн-контрактів і оптимізувати транзакції в ланцюзі або етапи діяльності:
  • ШІ та безпека: технологію ШІ можна використовувати для підвищення безпеки та захисту конфіденційності транзакцій у мережі. Наприклад, платформа безпеки Web3 SeQure використовує AI для виявлення та запобігання зловмисним атакам, шахрайству та витоку даних, а також забезпечує моніторинг у реальному часі та механізми сигналізації для забезпечення безпеки та стабільності транзакцій у ланцюжку;
  • ШІ та оптимізація діяльності в ланцюжку: діяльність у блокчейні включає транзакції, виконання контрактів і зберігання даних. Завдяки можливостям інтелектуального аналізу та прогнозування ШІ можна краще оптимізувати дії в ланцюжку та підвищити загальну ефективність і продуктивність. Штучний інтелект може допомогти визначити шаблони транзакцій, виявити незвичайну активність і надати рекомендації в реальному часі для оптимізації розподілу ресурсів для мереж блокчейну за допомогою аналізу даних і навчання моделі.
  • **Отже, оновлення Cancun буде від розширення простору для зберігання до інтеграції з ** ZK Доповнюваність зведення ** та поєднання з ** AI ** технологією поступово принесе користь майбутньому розвитку абстракції облікових записів. **

**6.**Озираючись на дорожню карту Ethereum, що буде далі

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

** Бич**

  • Мета: зосередитися на вирішенні проблем MEV.
  • Рішення: мінімізуйте MEV на прикладному рівні за допомогою «Розділення пропонента-конструктора (PBS)». У цей час блоби можуть бути оптимізовані, а також можуть бути запроваджені служби попереднього підтвердження або захист із випередженням.
  • PBS - це поділ виробників блоків і сортувальників. Сортувальник відповідає лише за сортування, незалежно від ланцюжка, а творець блоку не піклується про транзакцію, а безпосередньо вибирає пакет, створений сортувальником, і поміщає його в ланцюжок. Цей процес зробить весь процес більш справедливим і полегшить проблеми MEV, що є ідеєю екстерналізації MEV.
  • Ступінь завершеності PBS ще дуже низький, а більш зрілі Співпраця із зовнішніми рішеннями MEV - mevboost by flashbots.
  • Розширена версія «Enshrined Proposer-Builder Separation (ePBS)" має нижчий ступінь завершеності та довший цикл, і, за оцінками, він не буде реалізований у короткостроковій перспективі. Крім того, існують прогресивні версії PEPC та Optimistic Ретрансляція, яка підвищує гнучкість і адаптивність структури PBS

** Грань**

  • Мета: використовувати дерево Verkel для заміни Merkle, запровадити рішення для мінімізації довіри, дозволити легким вузлам отримати таку саму безпеку, що й повні вузли, і зробити перевірку блоків максимально простою та портативною.
  • У той же час ZK-версія L1 явно додається до дорожньої карти Verge. ZK буде загальною тенденцією майбутнього розширення та прискорення;
  • Рішення: запровадження zk-SNARK для заміни старої системи перевірки, включаючи легкі клієнти на основі SNARK; SNARK для консенсусних змін стану; Закріплено Зведення.
  • Дерева Verkle — це ефективніша альтернатива деревам Merkle, які залежать від стану, і їм не потрібно надавати шлях від кожного сестринського вузла (вузли, що мають спільний батьківський вузол) до вибраного вузла, а лише сам шлях як доказ. Частина Verkle докази в 3 рази ефективніші, ніж докази Merkle.
  • Закріплений Зведений пакет відноситься до зведеного пакета, який має певну консенсусну інтеграцію на L1. Перевага полягає в тому, що він успадковує консенсус L1 і не потребує маркерів управління для виконання зведених оновлень. У той же час, виконуючи обчислення поза ланцюгом і лише публікуючи результатів для блокчейну, це може збільшити кількість транзакцій, але технічна складність впровадження є відносно великою. Комбінація цих зведених у майбутньому зможе задовольнити більшість потреб екосистеми блокчейнів у наступні кілька десятиліть.

** очищення**

Purge відноситься до мети спростити протокол шляхом зменшення вимог до пам’яті для участі в перевірці мережі. Це в першу чергу досягається за допомогою сплячки та управління історією та станом. Неактивність історичних даних (EIP-4444) дозволяє клієнтам обрізати історичні дані, старші за рік, і припинити обслуговування на рівні P2P.

  • Стан сплячого стану. Коли мова заходить про зростання стану, є дві основні цілі: слабка бездержавність, що відноситься до цілі використання стану лише для створення блоку, але не для його перевірки; стан, до якого здійснюється доступ. Сплячий режим має зменшити стан, який вузол повинен зберігати, загалом на 20-50 GB.
  • На п'ятому етапі Purge, EIP 4444 явно вказано в Дорожній карті, EIP-4444 вимагає від клієнта очистити дані старше одного року, і на цьому етапі все ще є певна робота з оптимізації EVM, наприклад спрощення механізму попередньої компіляції GAS і EVM тощо;

** Розпилятися**

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

Довідкові матеріали:

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