Наближається оновлення Ethereum Cancun, огляд минулого, теперішнього та майбутнього оновлення Cancun

Автор: Fat Bird Finance

минулі життя

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

Бачення 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 як ядром, тому оновлення в Канкуні для вирішення проблеми TPS, плати за газ і досвіду розробників має вирішальне значення для дорожньої карти Ethereum.

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

Останні важливі оновлення та їхні цілі

1 грудня 2020 року було офіційно випущено ланцюжок маяків, що відкриває шлях для оновлень POS

Лондонське оновлення 5 серпня 2021 року EIP1559 змінило економічну модель Ethereum;

15 вересня 2022 року оновлення в Парижі (TheMerge) завершило перехід POW на POS;

12 квітня 2023 року Шанхай був модернізований, щоб вирішити проблему зняття застави;

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

Наступний крок зосереджений на TheSurge у дорожній карті Ethereum.

Мета: досягти 100 000+ TPS у Rollup.

В основному є два рішення: on-chain і off-chain:

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

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

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

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

Danksharding — це новий дизайн шардингу, запропонований для Ethereum. Його основною ідеєю є централізоване створення блоків + децентралізована перевірка + стійкість до цензури. Це також пов’язано з вибіркою доступності даних (DAS) і виробниками блоків, згаданими нижче. — Розділення пакетів (PBS) і цензура Пов’язані зі стійкими списками (Crlist). Найбільше значення основної ідеї Danksharding полягає в тому, щоб перетворити Ethereum L1 на єдиний рівень розрахунків і доступності даних (DataAvailability).

Схема шардингу поділена на 2 етапи.На даний момент вона поділяється на Proto-danksharding і Fully-Rollup.

Прото-danksharding:

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

Вміст: Основною особливістю прото-danksharding є запровадження нового типу blob-транзакцій. Blob має характеристики великої ємності та низької вартості. Додавання таких пакетів даних до Ethereum може дозволити зберігати всі зведені дані в blob, значно зменшуючи зберігання основного ланцюга тиску, але також зменшити вартість згортання.

Повністю зведене

Вступ: Rollup повністю розширює ємність, зосереджуючись на використанні доступних даних.

зміст:

P2P-дизайн DAS: деякі роботи та дослідження, пов’язані з проблемою мережевого підключення до шардингу даних;

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

Ефективне самовідновлення DA: здатне ефективно відновлювати всі дані за найгірших умов мережі (наприклад, атака зловмисного валідатора або тривалий простой великих блокових вузлів).

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

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

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

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

Існує два типи зустрічей, а саме зустріч консенсусного рівня та зустріч виконавчого рівня, які проводяться по черзі через тиждень:

Конференція консенсусного рівня (AllCore Developers Consensus - ACDC), зосереджена на консенсусному рівні Ethereum (Proof of Stake, Beacon Chain тощо);

Конференція виконавчого рівня (рішення AllCore Developers - ACDE), яка зосереджена на рівні виконання Ethereum (EVM, розклад газу тощо).

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

AllCoreDevs: супроводжувачі коду, відповідальні за мережевий клієнт ETH1, оновлення, підтримку коду Ethereum і базової архітектури;

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

EthereumMagicians: «Форум» для бажаючих обговорити EIP та інші технічні теми.

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

Відповідно до змісту дискусії, цю канкунську модернізацію можна умовно розділити на п’ять етапів.

Перший етап - впровадження теми оновлення

Ознайомтеся з новими завданнями: proto-danksharding, EOF і коди операцій "selfdestruct", коротко обговоріть вміст оновлення в Шанхаї

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

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

2 фаза - Визначення часових рамок і підготовка до церемонії КЗГ

Наприкінці 2022 року конференція Ethereum буде в основному зосереджена на EOF і EIP4844. У той же час ми продовжуватимемо просувати церемонію попереднього налаштування, яка вимагається EIP4844 – церемонію KZG. Розробники офіційно визначатимуть, у якому оновленні 4844 буде з'являться 23 січня

22 листопада EOF або proto-danksharding було згадано на телефонній конференції № 149 усіх основних розробників Ethereum. На даний момент розробники все ще розглядають можливість розміщення його в оновленні Shanghai;

Під час зустрічі Consensus Layer 12/02/22 Трент Ван Еппс, керівник екосистеми Ethereum, поінформував про хід церемонії довіреного налаштування, необхідної для впровадження EIP4844, метою якої є створення фрагмента безпечного коду, який буде використовується в EIP4844. VanEpps сподівається, що церемонія стане однією з наймасштабніших у криптопросторі, зібравши від 8 000 до 10 000 внесків. Період публічних внесків церемонії триватиме близько 2 місяців і розпочнеться десь у грудні;

Під час основної зустрічі розробників того ж дня відбулася дискусія навколо EOF і деактивації коду операції самознищення. Певний розробник Ethereum Foundation заперечував проти перенесення EOF до Канкуна, стверджуючи, що якщо зміни коду не включено в Шанхай, це увійде. Можливість Cancun дуже мала. Щодо коду самознищення, деякі розробники в той час виступали за просування EIP4758, але пряме вимкнення цього коду операції призведе до поломки деяких програм. Розробники вважають, що перед створенням крайнього випадку для захисту цього типу контракту, Цей EIP слід знову зважити протягом певного періоду часу;

На основній нараді розробників 9, 22 грудня було запропоновано реалізацію церемонії KZG щодо оновлення Канкуна. Наразі надійна церемонія налаштування, яка вимагається EIP4844, готова;

На зустрічі рівня консенсусу 16.12.22, присвяченій темі EIP4844, розробники обговорили об’єднання двох різних запитів на отримання (PR) у специфікації для прото-danksharding, одна з яких пов’язана з тим, як вузли обробляють дані, вирізані з One. коли в певному блоці відсутня інформація про блоби, буде введено новий код помилки для сповіщення вузлів;

На основній нараді розробників 5 січня 23 розробники досягли консенсусу щодо видалення модифікацій коду, пов’язаних із реалізацією EOF, з оновлення в Шанхаї. У цей час Бейко запропонував вирішити, чи слід включати EOF у перешкоду через два тижні. Кун модернізується;

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

Наприкінці 23 січня EOF було перенесено до Канкуна для оновлення після видалення з Шанхаю. У наступні два місяці дискусії в основному зосереджувалися на інших пропозиціях, крім EOF та EIP4844. У той же час EOF було запропоновано переїхати з Канкуна . Цей період часу в основному був витрачений на окреслення масштабів пропозицій щодо модернізації Канкуна.

На основній нараді розробників 20 січня 23 року EOF було перенесено до Канкуна для оновлення;

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

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

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

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

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

12, 23 квітня було завершено оновлення Ethereum Shanghai;

На додаток до основної наради розробників 13.04.23, де розробники обговорювали EIP4844 (для надання даних про кореневий стан CL у EL), існує принаймні дев’ять інших EIP, які розглядаються для оновлення. Це EIP4844, видалення SELFDESTRUCT ( EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIPs (EIP6601 і EIP6690), SSZchanges (EIP6475, EIP6493, EIP 6465, EIP6404 і EIP6466), E IP5656 і EIP6193;

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

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

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

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

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

Розробку 4844 коротко обговорили на нараді консенсусу розробників 18 травня 2023 р., наприклад дозволити додаткам смарт-контрактів на EL перевіряти докази стану CL;

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

На 110-й зустрічі рівнів консенсусу Ethereum 1 червня 2023 року дослідник з Ethereum Foundation представив результати експерименту з даними щодо здатності вузлів основної мережі Ethereum поширювати великі обсяги даних. З цього результату дослідник припустив, що EIP4844 The специфікацію збільшено з максимум 4 blobs до 6 на блок. У той же час розробники розглядають можливість включення EIP4788 в оновлення Cancun;

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

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

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

Під час консенсусної зустрічі 29 червня 2023 року розробники продовжили обговорення кількості blob-об’єктів, підвищили цільовий ліміт blob-об’єктів з 2 до 3 і підняли максимальний ліміт blob-об’єктів з 4 до 6. У той же час 4844 testnet Devnet #7 незабаром буде запущено.

це життя

Основним вмістом є EIP4844, Proto-Danksharding

Кінцеві діапазони EIP для оновлення в Канкуні такі: EIP4844, EIP1153, EIP5656, EIP6780 і EIP4788. У той же час на 111-й зустрічі Ethereum ACDC 19 червня розробники продовжили обговорення EIP6988, EIP7044 і EIP7045 для включення в Deneb. Розробники заявили, що планують об’єднати три вищезазначені EIP у специфікацію Deneb найближчими тижнями.

Аналіз ключових EIP

EIP4844

вступ:

Назва пропозиції EIP4844 — Proto-Danksharding, що є рішенням перед шардингом для повної версії Danksharding.Весь набір схем шардингу насправді обертається навколо Rollup для розширення в мережі. Мета рішення полягає в тому, щоб розширити Layer 2 Rollup, допомагаючи L2 зменшити комісію та збільшити пропускну здатність, прокладаючи шлях для повного шардингу.

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

На зустрічі розробників 23 і 23 червня розробники збиралися оновити попередньо скомпільовану адресу EIP4844. Наразі основні розробники додали 9 прекомпіляцій до EVM і створять дві прекомпіляції за адресами «0xA» та «0xB», активувавши EIP4844 та 4788 відповідно. Під час консенсусної зустрічі 29 червня було підготовлено Devnet#7, спеціальну короткострокову тестову мережу для EIP4844.

EIP-4844 представляє абсолютно новий тип транзакцій – BlobTranscation.

Знайомство з blobs:

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

Це може мати певний вплив на стабільність мережі, але команда розробників Ethereum все ж вирішила спочатку протестувати його, щоб уникнути необхідності подальших хардфорків для розширення блоку blob.

Blob використовує хеш KZGcommit як хеш для перевірки даних, подібно до Merkle;

Після того, як вузол синхронізує BlobTransaction у ланцюжку, термін дії частини 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 днів). рішення:

DataAvailability Sampling - зменшує навантаження на вузол

Розділіть дані в Blob-об’єкті на фрагменти даних і дозвольте вузлам переходити від завантаження Blob-даних до випадкової перевірки фрагментів Blob-даних, щоб фрагменти Blob-даних були розкидані по кожному вузлу Ethereum, але всі дані Blob зберігалися. у всій реєстрі Ethereum In Fang передумовою є те, що вузли мають бути достатніми та децентралізованими;

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

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

Вузли з високопродуктивними конфігураціями можуть стати конструкторами. Розробникам потрібно лише завантажувати дані blob-об’єктів для кодування та створювати блоки, а потім транслювати на інші вузли для вибіркових перевірок. Для розробників, оскільки обсяг даних синхронізації та вимоги до пропускної здатності є високими, це буде відносно централізований;

Вузол із низькою конфігурацією продуктивності може стати пропонентом (Proposer). Пропоненту потрібно лише перевірити дійсність даних і створити та передати заголовок блоку (BlockHeader). Однак для пропонента (Proposer) кількість синхронних даних і вимоги до пропускної здатності відносно високі. Низькі, тому він буде децентралізованим.

Антицензурний список (crList) — вирішує проблему, через яку пакувальники можуть навмисно ігнорувати певні транзакції та вставляти транзакції, які вони хочуть отримати, щоб отримати MEV, через їхні надмірні можливості перегляду.

Перед тим, як розробник (Builder) запакує блокові транзакції, пропонент (Proposer) опублікує антицензурний список (crList), який містить усі транзакції в mempool;

Розробник (Builder) може вибрати лише упаковку та сортування транзакцій у crList, що означає, що розробник не може вставити власну приватну транзакцію для отримання MEV, а також він не може навмисно відхилити транзакцію (якщо Gaslimit не заповнено);

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

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

Двослотова PBS - вирішує проблему, пов’язану з тим, що централізовані пакувальники стають все більш централізованими завдяки придбанню MEV

Для визначення блоку використовуйте режим ставок:

Конструктор (Builder) створює заголовок блоку списку транзакцій після отримання crList і ставок;

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

Верифікаційна комісія (Комітети) підтверджує переможний заголовок блоку;

Будівельник розкриває тіло виграшного блоку;

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

значення:

По-перше, розробник (Builder) має більше повноважень для пакетування транзакцій, але crList, згаданий вище, по-перше, обмежує можливість тимчасового вставлення транзакцій, а по-друге, якщо розробник (Builder) хоче отримати прибуток, змінюючи порядок транзакцій, його It необхідно сплатити великі витрати на тендері на початку, щоб переконатися, що він може отримати кваліфікацію керівника блоку, тоді отриманий прибуток MEV буде ще більше зменшено, і в цілому це матиме вплив на засоби та фактичну вартість отримання MEV;

Однак на ранній стадії лише невелика кількість людей може стати пакувальниками (враховуючи проблеми з продуктивністю вузла), тоді як більшість людей стають лише пропонентами, що може призвести до подальшої централізації.В той же час, коли сама кількість пакувальників дуже велика малий. За певних обставин деякі досвідчені майнери з можливостями MEV матимуть більше шансів зробити успішні ставки, що додатково вплине на фактичний ефект рішення MEV;

Це має наслідки для деяких рішень MEV, які використовують аукціони MEV.

значення:

EIP4844 насправді є надзвичайно спрощеною версією Danksharding: він забезпечує той самий інтерфейс програми, що й Danksharding, включаючи новий код операції під назвою DataHash і новий об’єкт даних під назвою BinaryLarge Objects, який є Blob;

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

Чому ви обираєте прото-danksharding замість EIP4488, щоб напряму знизити плату за Layer2 у довгостроковій перспективі, тому що під час оновлення до повного сегменту в майбутньому потрібно лише невелике коригування:

Основна практична відмінність між EIP4488 і proto-danksharding полягає в тому, що EIP-4488 намагається мінімізувати зміни, які Ethereum має зробити сьогодні, тоді як proto-danksharding вносить більше змін в Ethereum сьогодні, щоб оновити до Ethereum у майбутньому. необхідний для шардингу повної версії;

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

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

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

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

фон:

21 березня Віталік припустив, що SELFDESTRUCT приносить більше шкоди, ніж користі для екології Ethereum. Основна причина полягає в тому, що він єдиний, який може змінювати нескінченну кількість об’єктів стану в одному блоці, що призводить до зміни коду контракту, і може бути зміненим без згоди облікового запису Код операції балансу облікового запису має велику приховану небезпеку для безпеки Ethereum;

Єдиний спосіб видалити контракт у ланцюжку – САМОЗНИЩЕННЯ. Якщо ви викликаєте функцію самознищення в контракті, ви можете самознищити контракт. Ethereum, що зберігається в контракті, буде надіслано на вказану адресу. Решту коду та змінних зберігання буде видалено в кінцевому автоматі. Насправді дія розірвання контракту звучить добре в теорії, але насправді вона дуже небезпечна. Хоча функція самознищення може допомогти розробникам видалити смарт-контракт і перевести баланс у контракті на вказану адресу в екстрених випадках, ця функція також використовується злочинцями, що робить її засобом атаки.

На основній нараді розробників 13, 23 квітня для участі в обговоренні було представлено чотири пропозиції щодо SELFDESTRUCT, а саме 6780, 4758, 6046 і 6190, а наступну пропозицію EIP6780 було визначено як остаточну пропозицію.

Вступ: selfdestruct — це екстрена кнопка смарт-контракту, яка знищує контракт і переказує залишок ETH на призначений рахунок.

EIP6780: вимкніть SELFDESTRUCT, якщо вони не знаходяться в одній транзакції в контракті.

ОНОВЛЕННЯ: 26 травня Тім запропонував окрім видалення SELFDESTRUCT додати ще один код операції – SETCODE, щоб програмні облікові записи все ще оновлювалися. (Тобто додається функція оновлення, а властивість смарт-контракту оновлюється за допомогою оновлення/оновлення.) Тут поглинаються переваги EIP4758, що дозволяє dapp мати місце для оновлення.

Причина: маніпулювання кодом SELFDESTRUCT спочатку вимагало серйозних змін у стані облікового запису, наприклад видалення всіх кодів і пам’яті. Це створює труднощі для використання дерев Verkle у майбутньому: кожен обліковий запис зберігатиметься в багатьох різних ключах облікового запису, які не будуть явно пов’язані з кореневим обліковим записом.

ЗМІНЕНО: цей EIP реалізує зміну, яка видаляє SELFDESTRUCT, за наступними двома винятками

Програми, які використовуються лише для виведення коштів із SELFDESTRUCT, усе ще працюватимуть;

SELFDESTRUCT, який використовується в тій самій транзакції в контракті, також не потрібно змінювати.

Значення: підвищення безпеки

Раніше в основній мережі існував контракт, який використовував SELFDESTRUCT для обмеження того, хто може ініціювати транзакції через контракт;

Щоб завадити користувачам продовжувати вносити кошти та торгувати в сховищі після САМОЗНИЩЕННЯ, це сховище може змусити будь-кого вкрасти токени в сховищі під час повторного використання.

Наступні три пропозиції – це пропозиції, пов’язані з SELFDESTRUCT, які згодом були видалені.6780 було офіційно обрано на основній зустрічі розробників 28, 23 квітня, а решта трьох пропозицій було залишено, оскільки команда розробників Ethereum зрештою захотіла повністю видалити код операції SELFDESTRUCT, і в наступні три пропозиції внесено додаткові зміни шляхом заміни.

EIP-4758 (ЗАСТАРІЛО): вимкніть SELFDESTRUCT, змінивши SELFDESTRUCT на SENDALL, що відновлює всі кошти абоненту (надсилає весь ether в обліковому записі абоненту), але не видаляє код або сховище.

Причина: те саме, що й вище, попередні маніпуляції з кодами SELFDESTRUCT вимагали серйозних змін у стані облікового запису, наприклад видалення всіх кодів і пам’яті. Це створює труднощі для використання дерев Verkle у майбутньому: кожен обліковий запис зберігатиметься в багатьох різних ключах облікового запису, які не будуть явно пов’язані з кореневим обліковим записом.

змінити:

Код операції SELFDESTRUCT перейменовано на SENDALL, тепер лише переміщує весь ETH в обліковому записі абоненту, схема більше не порушує код і сховище, а також не змінює nonces;

Усі пов’язані відшкодування 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.

Крім того, є EIP1153, який економить газ і прокладає шлях для майбутнього дизайну сховищ

EIP1153X

Підсумок: тимчасові коди операцій для зберігання, додайте коди операцій для маніпулювання станом, який поводиться так само, як і зберігає, але скидається після кожної транзакції.

причина:

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

Наразі ці фреймворки можуть спілкуватися двома способами: введення/виведення через інструкції CALL та через оновлення магазину. Зв’язок через введення/виведення є небезпечним, якщо існує проміжна структура, що належить до іншого ненадійного контракту.

Взявши як приклад блокування повторного включення, він не може покладатися на проміжні кадри для передачі стану блокування: зв’язок SSTORE SLOAD через сховище коштує дорого, а тимчасове сховище є виділеним і ефективним рішенням проблеми міжкадрового зв’язку.

Змінено: два нові коди операцій додано до EVM, TLOAD (0xb3) і TSTORE (0xb4).

Тимчасове сховище є приватним для контракту, якому воно належить, і, як і постійне сховище, лише структура контракту-власника може отримати доступ до його ефемерного сховища. Під час доступу до сховища всі кадри отримують доступ до того ж ефемерного сховища так само, як і до постійного сховища, але інакше, ніж до пам’яті.

Потенційні випадки використання:

вхідний замок;

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

Схвалення однієї транзакції EIP-20, наприклад #temporaryApprove(addressspender, uint256 сума);

Контракт комісії за переказ: сплачуйте комісію за контракт токена, щоб розблокувати перекази під час транзакцій;

Режим «до»: дозволяє користувачеві виконувати всі операції як частину зворотного виклику та перевіряє, чи збалансовано «до» в кінці;

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

значення:

Економте газ і простіші правила виставлення рахунків за газ;

Вирішити задачу міжкадрового зв'язку;

не змінює семантику існуючих операцій;

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

Майбутні проекти зберігання (наприклад, дерева Verkle) не потребують розгляду питання повернення платежів для миттєвого зберігання.

Потім є 4788, який може зменшити припущення про довіру пулу застав

EIP4788：X

Коротко: корені блоку маяка в EVM.

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

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

Значення: це пропозиція модифікації коду, яка пропонує модифікувати віртуальну машину Ethereum (EVM), щоб вона могла розкривати дані кореня стану рівня контракту (CL) на рівні виконання (EL), що може створювати різні протоколи та програми в мережі Ethereum. Зв’язок між програмами більш ефективний і безпечний. Дозволяють більш надійні проекти для пулів стейкингу, протоколів з’єднання та повторного ставлення.

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

EIP5656X

Вступ: MCOPY - інструкція копіювання в пам'ять.

ОНОВЛЕННЯ: 09.06.23 команда розробників заявила, що спочатку вони розділилися щодо MCOPY, оскільки, хоча це вирішило проблему безпеки, вони були стурбовані пропускною спроможністю реалізації та тестування, необхідною для додавання цього до оновлення, але зрештою погодилися включити EIP Однак, якщо розробник зіткнеться з проблемами пропускної здатності під час тестування або на стороні клієнта, його буде розглянуто для видалення. Таким чином, MCOPY знаходиться в стані тимчасового включення в оновлення Канкуна.

Змінено: надано ефективну інструкцію EVM для копіювання областей пам’яті.

Значення: копіювання пам’яті є фундаментальною операцією, але її реалізація на EVM вимагає витрат.

Завдяки наявності інструкції MCOPY кодові слова та речення можна копіювати точніше, що збільшить продуктивність копіювання пам’яті приблизно на 10,5%, що дуже корисно для різноманітних операцій із інтенсивним обчисленням;

Також було б корисно для компіляторів генерувати більш ефективний і менший байт-код;

Це може заощадити певну кількість газу для попередньої компіляції ідентичності, але насправді не може сприяти реалізації цієї частини.

Список кандидатів ЕІП

15 і 23 червня на консенсусній зустрічі розробників обговорювалося, які EIP, орієнтовані на CL, включити в Deneb, серед яких було запропоновано додати EIP6988, EIP7044 і EIP7045.

EIP6988：X

Резюме: запобігає обранню валідаторів із посіченими лініями як пропонентів блоків.

Важливість: посилення штрафів за порушення вузлів піде на користь ТГВ.

EIP7044：X

Підсумок: переконайтеся, що підписані виходи валідатора є постійними.

Значення: це може певною мірою покращити досвід стекера.

EIP7045：X

Підсумок: розширено діапазон включення інтервалів атестації з ковзаючого вікна однієї епохи до двох епох.

Значення: підвищення безпеки мережі.

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

На 160-му засіданні ACDE Ethereum 29, 23 квітня було підтверджено, що EVMMAX і EOF будуть видалені з цього оновлення, а зміни, пов’язані з EOF, можуть бути внесені в наступні щоденні оновлення

EVMMAXEIP:

Підсумок: EVMMAX має на меті забезпечити більшу гнучкість арифметичних операцій і схем підпису в Ethereum. На даний момент є дві пропозиції EVMMAX, одна з EOF і одна без EOF.

EIP6601: модульні арифметичні розширення EVM (EVMMAX)

Зміна: це ітерація EIP5843, відмінність від EIP5843:

6601 представляє новий тип розділу EOF, який зберігає модуль, попередньо обчислений параметр Монтгомері, кількість значень, які будуть використовуватися (настроюваний модуль під час виконання все ще підтримується);

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

6601 підтримує операції з модулями до 4096 біт (попереднє обмеження, згадане в EIP).

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

Як контракт EVM, що дозволяє виконувати арифметичні операції з еліптичною кривою на різних кривих, включаючи BLS12-381;

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

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

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

EIP6690:

Зміна: 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 зможе виконувати контроль версій і запускати кілька наборів правил контракту одночасно.

EIP663:

Коротко: необмежена кількість інструкцій SWAP і DUP

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

EIP3540:

вступ:

Раніше байт-код EVM, розгорнутий у ланцюжку, не мав попередньо визначеної структури, і код лише перевірявся перед запуском у клієнті. Це не лише непрямі витрати, але й заважає розробникам запроваджувати нові функції Або відмовитися від старої функції.

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

значення:

Контроль версій сприяє впровадженню або припиненню нових функцій у майбутньому (таких як введення абстракції облікового запису);

Розділення коду контракту та даних є корисним для верифікації L2 (op), зменшуючи вартість газу для валідаторів L2. У той же час, відокремлення коду контракту та даних також є більш зручним для роботи інструментів аналізу даних у мережі .

EIP3670:

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

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

EIP4200:

вступ:

Представлено перші коди операцій, специфічні для EOF: RJUMP, RJUMPI та RJUMPV, які кодують пункти призначення як безпосередні значення зі знаком. Компілятори можуть використовувати ці нові коди операцій JUMP для оптимізації витрат газу на розгортання та виконання JUMP, оскільки вони усувають час виконання, необхідний для аналізу jumpdeanalysis для існуючих кодів операцій JUMP і JUMPI. Цей EIP є доповненням до dynamicjump.

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

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

EIP4750:

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

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

EIP5450:

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

Вміст: додано ще одну перевірку дійсності для контрактів EOF, цього разу навколо стека. Цей EIP запобігає ситуаціям, коли розгортання контракту EOF може призвести до недоповнення/переповнення стека. Таким чином, клієнти можуть зменшити кількість перевірок дійсності, які вони виконують під час виконання контрактів EOF.

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

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

EIP6475X

Вступ: додаткова пропозиція до EIP4844. Proto-danksharding представляє новий тип транзакцій, який використовує кодування SSZ замість кодування RLP, що використовується іншими типами транзакцій.

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

EIP6493X

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

Довідкова інформація: SSZchanges

Вступ: SimpleSerialiZe — це метод серіалізації, який використовується в ланцюжку маяків.

SSZchanges також включає три інші допоміжні пропозиції, цього разу представлено лише 6465.

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

EIP6404/ EIP6466:

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

EIP-6404 — корінь транзакції SSZ

EIP-6466— База отримання SSZ

На основній нараді розробників 26 травня Тім Бейко запропонував, щоб майбутні розмови щодо розширення масштабів Cancun обмежилися такими п’ятьма EIP: EIP5920, 5656, 7069, 4788 і 2537, і що подальші пропозиції будуть створені в рамках цього обсягу. Подальші EIP5656 і EIP4788 були підтверджені як офіційні пропозиції щодо оновлення, а 5920, 7069 і 2537 були видалені. Серед них EIP5920 був спричинений занепокоєнням розробників щодо можливих побічних ефектів способу передачі ETH, а також незавершеними міркуваннями, тестуванням, і робота з безпеки Вилучено з оновлення.

EIP5920：X

Вступ: код операції платежу. Представлено новий код операції PAY для переказів Ethereum, який надсилає Ether на адресу без виклику жодної з його функцій.

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

По-перше, це відкриває вектор для атак повторного входу, оскільки одержувач може передзвонити відправнику;

По-друге, він відкриває вектор DoS, тому батьківська функція повинна знати, що в приймачі може закінчитися газ або зворотний виклик;

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

змінити:

Було введено новий код операції: (PAY)PAY_OPCODE, де:

Витягти два значення зі стеку: addrthenval.

Передача wei з адреси виконання val на адресу addr. Якщо addr є нульовою адресою, valwei буде запрограмовано з адреси виконання.

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

Значення: економія газу.

ОНОВЛЕННЯ: 09.06.23 PAY було вилучено з оновлення через занепокоєння щодо можливих побічних ефектів, які можуть існувати під час передачі ETH, а також міркування, тестування та роботи з безпеки, необхідні для прийняття пропозиції.

EIP7069X

Введення: змінена інструкція CALL

Зміна: представлено три нові інструкції виклику, CALL2, DELEGATECALL2 і STATICCALL2, які мають ефект спрощення семантики. Має на меті вилучити з нової директиви можливість спостереження за газом і відкрити двері для нового класу контрактів, на які не впливає переоцінка.

фон:

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

Перш ніж було введено правила 63/64, доступний газ для абонента потрібно було розрахувати дещо точно. У Solidity є складне правило, яке намагається оцінити вартість виклику з боку абонента, пов’язаного з виконанням самого виклику, щоб встановити розумне значення газу.

Наразі введено правило 63/64:

Прибрана перевірка глибини виклику;

Переконайтеся, що зарезервовано принаймні 5000 газу перед виконанням викликаної поведінки;

Переконайтеся, що принаймні 2300 газу доступні для викликаної поведінки.

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

Значення: прокладіть шлях для впровадження EOF у майбутньому та спростіть виконання великих контрактів.

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

Із запровадженням нової пропозиції користувачі завжди можуть подолати помилку «Немає газу», надіславши більше газу в транзакції (звичайно, з урахуванням ліміту блокового газу).

Деякі контракти, які надсилали лише обмежену кількість газу для своїх викликів, були порушені новим механізмом калькулювання, коли раніше підвищувалися витрати на зберігання (наприклад, EIP-1884 збільшив обсяг газу для певних кодів операцій). Раніше деякі контракти мали обмеження на газ, яке назавжди обмежувало кількість газу, який вони могли витратити, навіть якщо вони надсилали його у свої субколли, це не спрацювало, незалежно від того, скільки додаткового газу вони надсилали, оскільки виклик обмежував би надіслана сума.

Прокладіть шлях для запровадження EOF: після введення EVM Object Format (EOF) старі інструкції виклику можна буде відхилити в контракті EOF, гарантуючи, що вони значною мірою захищені від змін ціни на газ. Оскільки ці операції необхідні для усунення спостережуваності газу, EOF вимагатиме їх замість існуючих інструкцій;

Більше зручних кодів повернення статусу: було представлено зручні функції, які повертають більш детальні коди стану: успіх (0), повернення (1), помилка (2), і їх можна розширити в майбутньому.

EIP2537：X

Коротко: попередня компіляція маніпуляції кривою BLS12-381.

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

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

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

PR3175：X

Підсумок: ця пропозиція не дозволить покараним валідаторам пропонувати блоки після виключення з черги. Якщо більше 50% валідаторів будуть покарані за зловмисну поведінку, ці валідатори все одно зможуть пропонувати блокування, будучи примусово видаленими з мережі. За словами розробників, зміна цієї логіки є відносно незначною зміною рівня CL, яка забезпечує захист від «високих режимів відмови».

Відповідно до 108-ї консенсусної зустрічі розробників Ethereum Core 4 травня PR3175 перебуває в процесі форматування як EIP і буде змінено на EIP-6987, тобто з міркувань безпеки, щоб запобігти вибору порізаних вузлів перевірки. пропонент блоку.

майбутнє

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

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

Немає сумніву, що розширення є першочерговим завданням (4844);

На другому місці – безпека та економія газу (6780, 1153, 5656 та 7045), враховуючи при цьому певний досвід розробника;

По-третє, це сумісність, така як оптимізація з’єднання, зв’язку та сумісності між прикладними програмами (4788, 7044 і 6988);

Очікувані дані: Testnet 4844 може знизити вартість opsiderollup на 50%; технічні рішення EigenLayer і Celestia не розкрили надто багато, і їхні дані неможливо оцінити; Ethstorage оцінює, що вартість DA впаде до 5% від початкової Очікується, що Topia зменшить вартість у 100-1000 разів.

2. Наступні 2-5 років, коли Cancun буде оновлено до Danksharding, є золотим періодом розробки для проектів рівня DA

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

По-перше, Danksharding повертається до суті кінцевої машини Ethereum. V God згадав, що мета консенсусного протоколу Ethereum не полягає в тому, щоб гарантувати постійне зберігання всіх історичних даних. Натомість ми маємо намір забезпечити високобезпечну дошку оголошень у режимі реального часу та залишити місце для інших децентралізованих протоколів для довгострокового зберігання (Мета консенсусного протоколу Ethereum не полягає в тому, щоб гарантувати вічне зберігання всіх історичних даних. Скоріше мета це забезпечити високобезпечну дошку оголошень у режимі реального часу та залишити місце для інших децентралізованих протоколів для довготривалого зберігання. );

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

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

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

У статті iablesecurity про шардинг даних від polynya про danksharding показано, що впровадження займе 2-5 років;

Навіть якщо він приземлиться, TPS, який він може збільшити, і рівень газу, який він може знизити, все ще обмежені:

Наразі EIP4844 підтримує 6 блобів, і проблему майбутнього розширення можна вирішити лише за допомогою Danksharding;

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

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

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

Існує дві основні витрати на DA: одна — це вартість пропускної здатності мережі, інша — вартість зберігання, а сам 4844 не вирішує проблему зберігання та пропускну здатність ланцюжка блоків.

Blob зберігатиметься на консенсусному рівні Ethereum протягом приблизно 3 тижнів, а потім буде видалено. Якщо ви хочете зберігати повні історичні записи та зробити всі дані доступними, поточні рішення включають: сам dapp зберігає дані, пов’язані з ним, і мережу порталу Ethereum (наразі в розробці) у розробці) або протоколи сторонніх розробників, такі як дослідники блоків, історичні дані в BitTorrent або спонтанне зберігання окремими користувачами.

Таким чином, Proto-Danksharding виграє від протоколів зберігання, модульних протоколів і мереж розширення зберігання L1:

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

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

Це добре для мережі розширення сховища L1, наприклад Ethstorage, яка може забезпечити рішення другого рівня для програмованого сховища за нижчої вартості зберігання.

3. Оновлення в Канкуні добре для різноманітності L2, L3, RAAS і доступності даних та інших треків

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

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

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

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

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

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

Але проблема з треком RAAS в тому, що це може бути OverHype, і навіть є сумніви щодо самого треку RAAS. Зіткнувшись із конкуренцією з 5 найкращих рівнів 2 і появою різноманітних нових DA, ми повинні поставити знак запитання, чи можуть нові проекти сформувати трек.

Перш за все, перевага розгортання ланцюга додатків головного рівня 2 полягає в цілісності мережевої структури та безпеці екології між ланцюгами, а перевага RAAS полягає в його налаштуванні та свободі;

Однак технічні бар’єри RAAS серії OP і ZK наразі не є сильними, і вони все ще перебувають на стадії тестової мережі в короткостроковій перспективі, і фактичної взаємодії продукту немає. Враховуючи фактичний прогрес RAAS, технічні форми та екологічні переваги шару 3 у майбутньому, фактичний попит на RAAS сумнівний.

Серія OP: хоча базове оновлення +4844 стека OP принесло деякі невеликі покращення у вартості та ефективності, привабливість, яку принесли вдосконалення, не є сильною;

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

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

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

Для звичайних програм DeFi та ринків NFT трансформація згортання не є жорсткою вимогою. Лише платіжні програми чи ігри, які вимагають високої ефективності, мають більший попит на зведення. У майбутньому проекти defi можуть бути на рівні 2, соціальні проекти можуть бути на рівні 3 або поза мережею, і, нарешті, основні дані та зв’язки розміщуватимуться на рівні 2. Ігрові проекти повинні перейти на рівень 3 або згортання, але враховуючи, що більшість поточних ланцюгові ігри — це, по суті, кошти, і нездатність жетонів циркулювати зовні призвела до вузьких місць у розробці, у поєднанні з появою ігор у всьому ланцюжку, екологічна привабливість самого l3 набагато більша, ніж rollup.

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

Друга важлива пропозиція оновлення в Канкуні, SELFDESTRUCTremoval, ще більше покращить безпеку Ethereum.У той же час, для проблем процедурного оновлення облікового запису, які можуть виникнути після видалення, новий код операції SETCODE готовий для покращення цієї ситуації;

Третя пропозиція EIP1153, оновлена Cancun, додає коди перехідних операцій зберігання, які можуть, по-перше, заощадити газ, по-друге, вирішити проблему міжкадрового зв’язку та, нарешті, прокласти шлях для майбутнього дизайну сховища, наприклад, дереву Verkle не потрібно буде розглядати відшкодування. питання тимчасового зберігання;

Четверта пропозиція оновлення в Канкуні, EIP5656, представляє інструкцію копіювання пам’яті MCOPY, яка може точніше копіювати кодові слова та речення, що покращить продуктивність копіювання пам’яті приблизно на 10%;

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

В останньому оновленні в Канкуні (15, 23 червня) пропонується додати оновлення EIP, орієнтовані на CL: EIP6988, EIP7044 і EIP7045, які покращують безпеку та зручність використання Ethereum у деталях, наприклад покращують досвід пледжера та покращують безпеку мережі тощо.

Серед видалених пропозицій перехід SSZ->RLP спричинив видалення двох SSZEIP (EIP6475 та EIP6493) з оновлення в Канкуні; пропозиції, пов’язані з EOF, були знову видалені з оновлення в Канкуні після видалення з оновлення в Шанхаї та наразі розглядаються можливо Це буде безпосередньо впроваджено в наступних щоденних оновленнях; EVMMAX також видаляється з Канкуна для оновлень разом із EOF, оскільки це підмножина EIP, пов’язана з впровадженням EOF; враховуючи потенційні побічні ефекти, які можуть існувати на шляху передачі ETH, і необхідність прийняти пропозицію. Обґрунтування, тестування та робота з безпеки, EIP5920 видалено з оновлення.

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

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

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

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

Можливість перевірки: технологія підтвердження з нульовим знанням має широкий спектр застосувань, а ZKP дозволяє користувачам знати правильність інформації без перевірки. І оскільки модель машинного навчання вимагає багато обчислень, модель ML може генерувати докази через ZK-SNARK, зменшуючи розмір доказів і зменшуючи вимоги до обчислювальної потужності ML.

Вимоги ZKML до сховища мають мало спільного з DA: потрібна окрема структура зберігання, як-от простір і час, а її основною технологією є новий протокол безпеки «SQL Proof». форматувати SQL і завантажувати результати безпосередньо в смарт-контракти;

ZK-SNARK є основною формою ZK у ZKML, яка може адаптуватися до вимог обчислювальної потужності ML у ланцюжку. З розвитком криптографії, особливо рекурсивні докази SNARK принесуть користь від реалізації ZKML у ланцюзі:

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

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

Поточна проблема ML більше пов’язана з незадоволеними вимогами до обчислювальної потужності та низькою продуктивністю, спричиненою обмеженнями алгоритму (неможливо обчислити паралельно). Велика модель ZK доводить, що потрібна більша обчислювальна потужність, яка не підтримується в ланцюжку. Поточна популярна ZK-SNARK підтримують лише невелике підтвердження масштабу ML з нульовим знанням і невеликий обсяг обчислень, тобто обмеження обчислювальної потужності є ключовим фактором, що впливає на розробку додатків блокчейну ZKML, і ланцюжок може зберігати лише результати -ланцюгові обчислення.

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

Перш за все, оновлення в Канкуні може певною мірою знизити вартість доказу ZKrollup:

Поточна комісія за транзакцію zkSync залежить від 3 аспектів:

Фіксована вартість ресурсів, споживаних верифікатором для створення сертифіката SNARK і його перевірки, є відносно високою;

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

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

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

По-друге, абстракція облікового запису перетворює традиційні транзакції передачі в операції користувача, а потім упаковує операції користувача в блоки за допомогою ECDSA, який займає більше пам’яті в ланцюжку, ніж раніше, тому вимоги до пам’яті вищі;

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

Наразі проблема абстрагування облікового запису полягає в тому, що GasFee дорогий. Оскільки є занадто багато кроків і задіяні смарт-контракти, є багато даних, що робить GasFee дорогим. Перевага ZKRollup полягає в тому, що він може зменшити дані;

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

Нарешті, враховуючи розвиток технології штучного інтелекту, це може допомогти підвищити безпеку онлайн-контрактів і оптимізувати онлайн-транзакції або етапи діяльності:

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

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

Таким чином, оновлення в Канкуні поступово сприятиме майбутньому розвитку абстракції облікових записів від розширення простору для зберігання до доповнення до ZKrollup, а потім до поєднання з технологією ШІ.

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

Наразі Layer2 не має продуктивності, подібної до Solana (з точки зору затримки та пропускної здатності), а також не має продуктивності фрагментації, як Near, а також не має продуктивності паралельного виконання, як Sui та Aptos. Оновлення в Канкуні покращило лідерство Ethereum як керівник;

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

TheScourge

Мета: Зосередитися на вирішенні проблем MEV.

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

PBS — це поділ творців блоків і сортувальників. Сортувальник відповідає лише за сортування, незалежно від ланцюжка, а творець блоку не піклується про транзакцію, а безпосередньо вибирає пакет, створений сортувальником, і поміщає його в ланцюжок. Цей процес зробить весь процес більш справедливим і полегшить проблему MEV, яка є ідеєю екстерналізації MEV.

Ступінь завершеності PBS наразі ще дуже низький, а більш зрілою є співпраця із зовнішніми рішеннями MEV – mevboost флеш-ботів.

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

TheVerge

Мета: використовувати дерево Verkel для заміни Merkle, запровадити рішення для мінімізації довіри, дозволити легким вузлам отримати таку саму безпеку, що й повні вузли, і зробити перевірку блоків максимально простою та портативною.

У той же час ZK-версія L1 явно додається до дорожньої карти Verge.ZK буде загальною тенденцією майбутнього розширення та прискорення;

Рішення: запровадьте zk-SNARK на заміну старої системи перевірки, включаючи легкі клієнти на основі SNARK; SNARK із консенсусними змінами стану; EnshrinedRollups.

Дерева Verkle є більш ефективною альтернативою деревам Merkle, які залежать від стану, і їм не потрібно надавати шлях від кожного сестринського вузла (вузлів, які мають один і той же батьківський вузол) до вибраного вузла, а лише сам шлях як доказ Частково докази Verkle в 3 рази ефективніші, ніж докази Merkle.

EnshrinedRollup відноситься до зведеного пакета, який має певну консенсусну інтеграцію на L1. Перевага полягає в тому, що він успадковує консенсус L1 і не потребує маркерів управління для виконання зведених оновлень. У той же час, виконуючи обчислення поза ланцюгом і лише публікуючи результатів для блокчейну, це може збільшити кількість транзакцій, але технічна складність впровадження є відносно великою. Комбінація цих зведених у майбутньому зможе задовольнити більшість потреб екосистеми блокчейну в найближчі кілька десятиліть.

Чистка

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

стан сплячого стану. Коли справа доходить до обробки зростання стану, є дві основні цілі: слабка бездержавність, яка стосується мети лише використовувати стан для створення блоків, але не перевіряти його; стан, до якого здійснюється доступ. Сплячий режим має зменшити потребу вузлів у стані для зберігання загалом на 20-50 ГБ.

На п’ятому етапі Purge EIP4444 явно записується в дорожню карту. EIP-4444 вимагає від клієнта очистити дані старше одного року. Водночас на цьому етапі є деякі завдання з оптимізації EVM, наприклад спрощення механізму попередня компіляція GAS і EVM;

TheSplure

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