Оновлення в Канкуні наближається. Які адаптації зробили основні L2?

TL;DR：

• Оновлення Cancun буде запущено 13 березня 2024 року, і незабаром EIP4844 буде в мережі. Danksharding є основою дорожньої карти Ethereum, і це оновлення є першим кроком до впровадження Danksharding.
• Після адаптації Ethereum L2 до EIP4844 комісія за транзакції значно знизилася, а TPS L2 подвоївся. **Користувачі відчують, що транзакції швидші, дешевші, зручніші та чуйніші. На цих L2 будуть складніші та більші програми Dapp. **
• Оптимістичні зведені легше адаптувати до EIP4844, тоді як зведені ZK адаптувати складніше**. Ethereum не має попередньо скомпільованого контракту для підтримки еліптичних кривих BLS12-381, що ускладнює певну перевірку ZKP і перешкоджає адаптації зведених пакетів ZK до EIP4844. **
• Проблему еліптичних кривих можна вирішити двома способами: 1. Зачекайте, доки Ethereum попередньо скомпілює еліптичні криві BLS12-381; 2. Використовуйте інший метод перевірки, щоб досягти тієї самої мети, використовуйте BN254, який підтримується попередньою компіляцією Ethereum.
• Наразі Arbitrum, Optimistic, Starknet, zkSync, Scroll, Polygon zkEVM і новий L2 Morph адаптуються до EIP4844. Серед них Arbitrum, Optimistic і Starknet заявили, що Cancun запровадить адаптацію EIP4844 після оновлення. Morph виступив лідером у випуску інноваційного рішення для адаптації zkSNARK zkEVM, яке стане першим zkSNARK zkEVM, адаптованим до EIP4844

1. Фон

У 2020 році Ethereum випустив «Дорожню карту Ethereum, орієнтовану на зведення», а остаточне зображення Ethereum, описане в «Endgame», опублікованому Віталіком наступного року, ** визначило загальну картину Ethereum. Напрямок: оптимізація конструкції базового рівня Ethereum для обслуговування Rollup. **

Ethereum розробив технологію шардингу Danksharding, щоб покращити зручність використання Ethereum як рівня доступності даних. Це значно зменшить комісію за транзакції L2, збільшить TPS Rollup і досягне значного розширення Ethereum.

До цього року оновлення Ethereum Cancun-Dencun було нарешті запущено 13 березня 2024 року, і EIP4844 ось-ось запуститься в Інтернет. Можна сказати, що цей хардфорк є першим кроком у впровадженні Ethereum Danksharding. Ядро дорожньої карти. **

Щодо рівня DA, технічних принципів Danksharding і вмісту EIP4844, зверніться до технічної статті, яку я написав минулого року: DA (Доступність даних) Літо наближається?

**2. Яку користь принесе оновлення в Канкуні L2? **

EIP4844 представляє новий тип транзакцій під назвою транзакції з blob-перенесенням**. **Кожна транзакція з переносом blob-об’єктів може «нести» список blob-об’єктів. Blob — це пакет даних розміром приблизно 125 КБ. Блоби зберігаються недовго, всього 4096 епох, тобто трохи більше 18 днів.

• Комісії за трансакції L2 значно знизилися. Оскільки Blobs не потребують постійного зберігання, Blobs більші та дешевші, ніж блоковий простір. Blob може зберігати в 10 разів більше даних, ніж Calldata, при такому ж споживанні газу. Зведений пакет, адаптований до EIP4844, може зберігати дані транзакцій у Blobs, зменшуючи комісію за транзакції на порядок.
• TPS L2 подвоюється. Поточна ціль — 3 краплі на блок, дозволено максимум 6 блоків. Блоки мають лише 90 КБ, а кожен blob — близько 125 КБ. Введення Blob еквівалентно збільшенню простору блоку в декілька разів для зберігання даних зведення, тому TPS зведення також можна подвоїти. А «Про збільшення ліміту блокового газу», написаного Тоні та Віталіком, зазначено, що шляхом збільшення ліміту блокового газу та ціни ненульових байтів Calldata буде досягнуто меншого розміру блоку з меншою кількістю змінних, щоб можна було додати більше майбутнє. Чим більше блоків, тим більше місця для зберігання.

Для кінцевих користувачів, після адаптації **EthereumL2 до EIP4844, швидкість транзакцій буде швидшою, вартість буде нижчою, досвід буде більш плавним, а відповідь буде більш чуйною. На цих L2 будуть складніші та більші програми Dapp. **

3. Як L2 адаптується до EIP4844?

Як L2 адаптується до EIP4844? Нам потрібно обговорити Optimistic Rollup і ZK Rollup окремо.

Optimistic Rollups адаптується до EIP4844

Optimistic rollup використовує захист від шахрайства, щоб забезпечити правильне виконання зведеного облікового запису. Тобто вузол спочатку вважає, що перехід стану правильний.Якщо хтось не ініціює сертифікат шахрайства протягом визначеного періоду часу, щоб довести, що раніше поданий перехід стану є незаконним, перехід стану буде скасовано.

Optimistic rollup простіше адаптувати до EIP4844, ніж ZK rollup. Щоб завершити адаптацію, надішліть усі транзакції L2 на L1 через транзакції Blob. Крім того, захист від шахрайства потрібно налаштувати для адаптації до EIP 4844. Цю частину можна виконувати повільно. Зрештою, багато оптимістичних зведень ще не запустили докази шахрайства. Я опублікував сертифікат про шахрайство в Інтернеті, але виявив, що жодного сертифіката про шахрайство не було подано більше двох років.

Подання транзакції L2: коли надсилається зведений пакет, транзакція, що переносить Blob, використовується для зберігання даних зведення в Blob. Корисним навантаженням транзакції, що переносить Blob-об’єкт, є rlp([tx_payload_body, blobs, commitments, proofs]), де

• tx_payload_body - це TransactionPayloadBody стандартної транзакції blob EIP-2718.
• blobs - список blobs. Транзакція може містити до двох блоків.
• зобов'язання - список зобов'язань KZG для blob.
• докази – блок і список доказів, що відповідають зобов’язанню KZG. Це підтвердження буде перевірено вузлом ETH.

Коригування для захисту від шахрайства:

• По-перше, тому, хто доводить і претендує, потрібні кілька раундів взаємодії, щоб знайти точку суперечки.
• Потім передайте спірне питання на розгляд L1. Щоб адаптуватися до EIP4844, може знадобитися довести, що спірні дані зберігаються в певному Blob.
• Оскільки Blob-дані буде видалено приблизно через 18 днів, до їх видалення має пройти період перевірки, що задовольняється поточними оптимістичними зведеними версіями. Як правило, період виклику не перевищує 7 днів.

ZK Rollups адаптується до EIP4844

Зведення ZK використовує ZKP, щоб довести, що перехід стану L2 правильний. Адаптація ZK rollup до EIP4844 є більш складною, ніж optimistic rollup.

1. Подання транзакції L2: цей крок Optimistic Rollup схожий.
2. **Подання доказів ZK: порівняно зі зведеним пакетом ZK перед адаптацією, окрім підтвердження переходу стану ZKP, потрібен ще один процес підтвердження. Тобто доведено, що зобов’язання blob і пакет транзакцій відповідають, таким чином гарантуючи, що введення підтвердження переходу стану є правильним. **
3. Наприклад: схема ZK переходу стану може генерувати доказ процесу обчислення a + a = b. ЗКП, створений, коли (a=1,b=2) і (a=2,b=4) є законним. Тому мені також потрібно надати доказ того, що введені мною дані були (a=1,b=2) замість (a=2,b=4).
4. Це не потрібно робити перед адаптацією до EIP4844, оскільки дані зберігаються безпосередньо в Calldata і можуть бути прочитані безпосередньо, гарантуючи, що вхідні дані не будуть скориговані. Після використання EIP4844 дані Blob неможливо прочитати безпосередньо, і це можна підтвердити лише за допомогою нової схеми.
5. Легше реалізувати цей механізм перевірки, використовуючи зведений ZK від STARK (наприклад, Starknet). Це проблема для зведення ZK із використанням SNARK. Причина така: **Еліптична крива, яка використовується в зобов’язанні blob EIP4844, — це BLS12-381, тоді як попередньо скомпільований контракт ETH підтримує лише BN254. Через різні криві нам важко Безпосередньо Перевірте підтвердження виконання зобов’язань blob у смарт-контракті. **
6. **ZkEVM/zkVM за допомогою SNARK має вирішити проблему, згадану в пункті 2, що доказ ZK не може бути створений через невідповідність кривих. **

• Очікується, поки Ethereum підтримає попередньо скомпільовані контракти BLS12-381. Це буде довго.
• Для доведення використовуйте інший метод доказу. Щоб розробити нові схеми, ви повинні використовувати еліптичну криву BN254, яка підтримується попередньо скомпільованим контрактом. Зараз ми бачимо, що Morph використовує цей підхід. Це також робить Morph першою zkEVM, яка завершила адаптацію EIP4844.

Інтегроване рішення Morph EIP-4844 zkEVM див.:

**4. Які L2 адаптовані до EIP4844? **

У зведеному пакеті Optimistic Optimism і Arbitrum висловили свою готовність прийняти EIP-4844 і тісно співпрацюють зі своїми спільнотами для тестування та розгортання необхідних оновлень. Arbitrum є зведеним етапом 1 і має відносно хороший рівень безпеки. Це передбачає необхідність адаптації захисту від шахрайства до EIP4844. Оптимістичний зведений пакет є етапом 0. Наразі немає доказів шахрайства. Його легше адаптувати, але рівень безпеки недостатньо високий.

У ZK rollup складність адаптації rollup за допомогою STRAK і SNARK різна. Простіше адаптувати EIP4844 за допомогою зведення STARK, одним із представників якого є Starknet. Starknet опублікував статтю про те, що Канкун запровадить адаптацію EIP4844 після оновлення (посилання на статтю). Використовуючи зведений пакет SNARK, zkSync також досліджує, як використовувати транзакції з перенесенням blob-об’єктів для подальшого зниження витрат і підвищення продуктивності. Минулого року Scroll опублікував статтю з ідеєю адаптації EIP4844 (посилання на статтю)

Найбільш вражаючим є Morph, який є Optimistic ZK Rollup і першим випустив рішення для адаптації zkEVM до EIP4844.**Це можна сказати, що це перший zkEVM Rollup, який завершує EIP4844. **

Optimistic ZK Rollup поєднує в собі переваги обох типів Rollup. Він оптимістично вірить у результати виконання, представлені Sequencer, і дозволяє тим, хто сумнівається в результатах, ініціювати виклики. Лише при подачі виклику прувер згенерує ЗКП для підтвердження правильності результатів виконання. **Він має ефективність Optimistic rollup і перевірену ZK надійність ZK rollup. **