Нове відео Віталіка: Майбутнє Ethereum, Спалах

Автор оригіналу: Віталік Бутерін

Переклад оригінального тексту: Карен, Foresight News

Особлива подяка Джастину Дрейку, Франческо, Сяо-вей Вангу, @antonttc та Георгіосу Константопулосу.

Спочатку в маршрутній карті ETH-блокчейна було дві стратегії масштабування. Одна (див. ранню статтю 2015 року) - це «Шардинг» (sharding): кожна Нода має перевіряти та зберігати лише частину транзакцій, а не всі транзакції в ланцюжку. Це працює у будь-яких мережах peer-to-peer (наприклад, BitTorrent), тому ми, звичайно, можемо зробити так, щоб блокчейн працював таким же чином. Інша - це протокол Рівень 2: ці мережі будуть вище ETH-блокчейна, дозволяючи йому повністю скористатися його безпекою, але зберігаючи більшість даних та обчислення поза основним блокчейном. Протокол Рівень 2 посилається на канали стану 2015 року, Plasma 2017 року, а потім Rollup 2019 року. Rollup потужніший за канали стану або Plasma, але для них потрібна значна пропускна здатність даних у блокчейні. На щастя, до 2019 року дослідження щодо Шардингу вирішили проблему масштабного підтвердження «доступності даних». Як результат, дві стежки були об’єднані, і ми отримали маршрутну карту, яка досі є стратегією масштабування ETH-блокчейна, з Rollup у центрі.

The Surge, версія дорожньої карти 2023

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

Цього року маршрутна карта, зосереджена на Rollup, досягла важливих результатів: з впровадженням EIP-4844 blobs ширина пропускання даних ETH L1 значно збільшилася, декілька варіантів Rollup EVM ETH L1 вже перейшли до першої фази. Кожен L2 існує як «Шардинг» з власними внутрішніми правилами та логікою, різноманітність та розмаїття методів реалізації Шардингу стали реальністю. Але, як ми бачимо, цей шлях також постає перед кількома унікальними викликами. Тому наше завдання зараз - завершити маршрутну карту, зосереджену на Rollup, і вирішити ці проблеми, зберігаючи при цьому стабільність і децентралізацію ETH L1.

The Surge: ключова мета

1. У майбутньому Ethereum може досягти понад 100 000 TPS за допомогою L2;

2. Зберігайте Децентралізацію та стійкість L1;

3, принаймні деякі L2 повністю успадковують основні властивості Ethereum (Ненадійний, відкритий, необхідний для перевірки)

4, Ethereum має бути сприйняте як єдину екосистему, а не 34 різних блокчейни.

Зміст цього розділу

• Трикутник непрацездатності масштабованості
• Подальший прогрес в зразках доступності даних
• Стиснення даних
• Загальний Плазма
• Зрілі системи доказів L2
• Покращення міжоператорної сумісності L2
• Розширення виконання на рівні L1

Тріада протиріччя розширюваності

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

Варто зазначити, що трикутна паралогія не є теоремою, і пости, що пояснюють трикутну паралогію, не мають математичного доведення. Вона дійсно надає евристичний математичний аргумент: якщо дружній до Децентралізації вузол (наприклад, споживацький ноутбук) може перевірити N транзакцій на секунду, і ви маєте ланцюжок, який обробляє k*N транзакцій на секунду, тоді (i) кожну транзакцію може побачити тільки 1/k вузол, що означає, що зловмиснику достатньо знищити кілька вузлів, щоб провести зловмисну транзакцію, або (ii) ваш вузол стане потужним, а ваш ланцюжок залишиться не децентралізованим. Мета цієї статті полягає не в доведенні, що розбиття трикутної паралогії неможливо; навпаки, вона спрямована на те, щоб показати, що розбиття трикутної паралогії є складним, і це вимагає виходу за рамки вбудованих мисленнєвих моделей цього аргументу.

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

Проте поєднання доступності даних та SNARKs дійсно вирішує трикутне протиріччя: воно дозволяє клієнту перевірити доступність певної кількості даних та правильність виконання певної кількості обчислювальних кроків, при цьому завантажуючи лише невелику кількість даних та виконуючи мінімум обчислень. SNARKs є недовіреними. В зразках доступності даних є витончена модель довіри “few-of-N”, але вони зберігають базові властивості нешкальованого ланцюжка, тобто навіть атаки на 51% не можуть змусити мережу приймати погані блоки.

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

Дальший прогрес у вибірковому забезпеченні доступності даних

Ми вирішуємо яку проблему?

13 березня 2024 року, коли Dencun оновлюється та запускається, у блокчейні Ethereum має місце 3 окремих блоки розміром приблизно 125 кБ кожен кожні 12 секунд, або приблизно 375 кБ доступної пропускної здатності для кожного блоку. За умови, що дані транзакцій будуть публікуватися безпосередньо на блокчейні, транзакція ERC 20 має приблизний розмір 180 байтів, тому максимальна швидкість обробки транзакцій на Rollup Ethereum становить: 375000 / 12 / 180 = 173.6 TPS

Якщо ми додамо calldata ETH-блоку (теоретичне максимальне значення: 30 млн газів на кожен слот / 16 газів на байт = 1,875,000 байт на кожен слот), то отримаємо 607 TPS. Використовуючи PeerDAS, кількість блобів може збільшитися до 8-16, що забезпечить calldata 463-926 TPS.

Це значний розвиток для L1 Ethereum, але недостатньо. Ми хочемо більше масштабованості. Наша середньострокова мета - 16 МБ на кожен слот, що, якщо поєднати з поліпшеннями стиснення даних Rollup, принесе більше 58000 TPS.

Що це таке? Як це працює?

PeerDAS - це відносно проста реалізація «1 D sampling». У блокчейні Ethereum кожен блоб є поліномом ступеня 4096 над простим полем з 253 бітами. Ми розповсюджуємо частки цього полінома, причому кожна частка містить 16 значень оцінки на 16 сусідніх координатах з усього 8192 координат. З цих 8192 значень будь-які 4096 (з 64 можливих зразків) можуть відновити блоб (відповідно до поточних параметрів: 128 можливих зразків з 64).

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

Теоретично ми могли б масштабувати «1 D дискретизацію» до значного розміру: якщо ми збільшимо максимальну кількість блобів до 256 (з цільовим показником 128), то ми зможемо досягти мети в 16 МБ і 16 зразків на Нода * 128 блобів * 512 байт на зразок на блоб = 1 МБ пропускної здатності даних на слот у вибірці доступності даних. Це ледве в межах нашої толерантності: це можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть брати вибірку. Ми можемо певною мірою оптимізувати це, зменшивши кількість ляпок і збільшивши розмір ляпки, але це робить її відновлення дорожчим.

Отже, нашим кінцевим бажанням є проведення подальших 2D вибірок (2D sampling), які не лише випадковим чином відбираються всередині блоку, але й між блоками. Використовуючи лінійні властивості обіцянок KZG, ми розширюємо набір блоків в Блоку за допомогою нового набору віртуальних блоків, що зайво кодують ту саму інформацію.

Отже, нарешті ми хочемо йти ще далі, роблячи вибірку 2D, яка відбувається не лише всередині блобу, а й між блобами. Лінійні властивості, які обіцяє KZG, використовуються для розширення набору блобів у блоку, який містить новий віртуальний список блобів, що кодують зайвість однакової інформації.

2D зразок. Джерело даних: a16z crypto

Важливо, що розширення обіцянок обчислення не вимагає наявності блобу, тому ця схема в основному є дружньою до розподіленої конструкції блоків. Фактично, Нода, що будується блоком, потребує тільки обіцянки blob KZG, і вони можуть спиратися на вибіркову доступність даних (DAS), щоб перевірити доступність блоку даних. Одновимірний вибірковий доступ до даних (1 D DAS) в основному є дружнім до розподіленої конструкції блоків.

Які посилання є на існуючі дослідження?

• Оригінальний пост про доступність даних (2018):
• Далі йдуть папери:
• Про пояснювальну статтю про DAS, парадигма:
• 2D доступність з обіцянкою KZG:
• PeerDAS на ethresear.ch: та стаття:
• EIP-7594:
• SubnetDAS на ethresear.ch:
• Незначні відмінності відновлюваності в 2D вибірці:

Що ще потрібно зробити? Які ще є компроміси?

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

На більш віддаленому етапі майбутнього нам потрібно зробити більше роботи, щоб визначити ідеальну версію 2D DAS та довести її безпечність. Ми також сподіваємося у кінцевому підсумку перейти від KZG до альтернативного рішення, яке є квантово безпечним та не потребує довіри. Зараз нам неясно, які кандидатські рішення є дружніми до побудови доказу дійсності. Навіть за використання дорогих технологій “brute-force”, навіть за використання рекурсивного STARK для створення доказу дійсності для відновлення рядків та стовпців, цього недостатньо, оскільки технічно розмір STARK складає O(log(n) * log(log(n)) хеш-значень (з використанням STIR), але фактично STARK майже такий же великий, як і весь блоб.

Я вважаю, що довгостроковим реалістичним шляхом є:

1. Впровадження ідеальної 2D DAS;
2. Прослідкуйте використання 1 D DAS, жертвуючи ефективністю смуги зразка, щоб прийняти більш низьку верхню межу даних для простоти та надійності.
3. (Твердий поворот) Відмовитися від DA і повністю прийняти Plasma як нашу основну архітектуру Рівня 2, на яку підписуємось.

Зверніть увагу, що навіть якщо ми вирішимо розширити виконання безпосередньо на L1, такий вибір все ж таки існує. Це через те, що якщо L1 повинен обробляти велику кількість TPS, L1 Блок стане дуже великим, і клієнти захочуть мати ефективний спосіб перевірити їх правильність, тому нам доведеться використовувати на L1 ту ж саму технологію, що й Rollup (таку як ZK-EVM і DAS).

Як взаємодіяти з іншими частинами дорожньої карти?

Якщо досягти стиснення даних, попит на 2D DAS буде зменшуватися, або принаймні буде затримка, якщо Plasma буде широко використовуватися, то попит ще більше зменшиться. DAS також створює виклики для протоколу та механізму побудови розподілених блоків: хоча в теорії DAS є дружелюбним до розподіленого відновлення, це потребує поєднання з пропозицією включення пакетів та навколишнім механізмом вибору форків у практиці.

Компресія даних

Яку проблему ми вирішуємо?

Кожна угода в Rollup займає великий обсяг даних у блокчейні: передача ERC 20 потребує приблизно 180 байтів. Навіть з ідеальним семплюванням доступної інформації про дані, це обмежує масштабованість протоколу Layer. З кожним слотом 16 МБ ми отримуємо: 01928374656574839201

16000000 / 12 / 180 = 7407 TPS

Якщо ми зможемо вирішити не тільки проблеми чисельника, але й проблеми знаменника, щоб кожна транзакція в Rollup займала менше байтів у блокчейні, що буде?

Що це таке і як воно працює?

На мій погляд, найкращим поясненням є ця фотографія з два роки тому:

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

Агрегація підписів: ми перейшли від підпису ECDSA до підпису BLS, характерною особливістю підпису BLS є можливість об’єднати кілька підписів в один єдиний підпис, який може підтвердити дійсність всіх початкових підписів. На рівні L1, враховуючи, що навіть при агрегації, обчислювальна вартість перевірки залишається високою, тому не розглядається використання підпису BLS. Але в середовищі L2, де дані рідкісні, використання підпису BLS має сенс. Особливість агрегації ERC-4337 надає можливість реалізувати цю функцію.

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

Серіалізація власного значення угод - більшість значень угод мають малу кількість цифр, наприклад, 0.25 ETH представляється як 250,000,000,000,000,000 wei. Найбільша базова комісія та пріоритетна комісія також схожі. Тому ми можемо використовувати власний десятковий формат з плаваючою комою, щоб представляти більшість валютних значень.

Які посилання є на існуючі дослідження?

• Дослідження sequence.xyz:
• Оптимізація контракту L2 Calldata:
• На основі роллапів з доказом дійсності (також відомих як ZK роллапи) стан випуску відрізняється від угод:
• BLS Гаманець - за допомогою ERC-4337 реалізовано BLS агрегацію:

Що ще потрібно зробити, які компроміси?

Наступним кроком є практична реалізація вищезазначеної схеми. Основні ваги включають:

1、Переключення на підпис BLS потребує великих зусиль, а також може призвести до Падіння сумісності з надійним апаратним забезпеченням, яке забезпечує підвищення безпеки. Його можна замінити обгорткою ZK-SNARK для інших схем підпису.

2、Динамічне стиснення (наприклад, заміна адрес pointers) ускладнить клієнтський код.

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

Як взаємодіяти з іншими частинами дорожньої карти?

Використання ERC-4337 і нарешті включення його частини в L2 EVM дозволяє значно прискорити розгортання агрегаційної технології. Розміщення частини вмісту ERC-4337 на L1 допоможе прискорити його розгортання на L2.

Загальний Плазма

Ми вирішуємо яку проблему?

Навіть з використанням 16 МБ блобу та стиснення даних, 58 000 TPS можуть бути недостатніми для повної задоволеності потреб споживачів у сферах, які потребують великої пропускної здатності, таких як оплата товарів і послуг, Децентралізація соціальних мереж або інших. Особливо коли ми починаємо розглядати питання приватності, це може знизити масштабованість на 3-8 разів. Для сценаріїв високого об’єму та низької вартості, один з варіантів - використання Validium, який зберігає дані поза блокчейном та використовує цікаву модель безпеки: оператор не може викрасти кошти користувачів, але він може тимчасово або назавжди заморозити кошти всіх користувачів. Однак ми можемо зробити краще.

Що це таке і як воно працює?

Plasma - це рішення для масштабування, яке передбачає, що оператор публікує Блоки поза блокчейном та розміщує корені Merkle цих Блоків на блокчейні (на відміну від Rollup, який розміщує повні Блоки на блокчейні). Для кожного Блоку оператор надсилає кожному користувачеві гілку Merkle, щоб підтвердити, що сталося зміна або нічого не змінилося з їх активами. Користувачі можуть витягнути свої активи, надавши гілку Merkle. Важливо, що ця гілка не обов’язково має корінь в найновішому стані. Тому, навіть якщо стан доступності даних порушено, користувачі все ще можуть відновити свої активи, витягнувши їх доступний найновіший стан. Якщо користувач надає недійсну гілку (наприклад, витягає активи, які він вже надіслав іншій особі, або оператор самостійно створює актив), то можна використати механізм викликів на блокчейні для перевірки законності передачі активів.

Ланцюг Plasma Cash. Угода з витратою монети i розміщується на позиції i в дереві. У цьому прикладі за умови, що всі попередні дерева є дійсними, ми знаємо, що зараз Ева має Токен 1, Девід має Токен 4, Джордж має Токен 6.

Ранні версії Plasma могли обробляти лише випадки оплати, і не могли ефективно розширюватися. Однак якщо ми вимагатимемо, щоб кожне дерево було перевірене за допомогою SNARK, то Plasma стане набагато потужнішою. Кожна гра викликів може бути значно спрощена через те, що ми виключаємо більшість можливих шляхів обману оператора. Також відкриваються нові можливості для розширення технології Plasma на більш широкий спектр активів. Нарешті, у випадку чесного поведінки оператора користувачі можуть негайно вилучати кошти, не чекаючи тиждень випробувального строку.

Спосіб створення ланцюга EVM Plasma (не єдиний спосіб): побудова паралельного дерева UTXO за допомогою ZK-SNARK, яке відображає зміни балансу, зроблені в EVM, і визначає унікальне відображення “Токен” в різний час в історії. Потім можна побудувати на ньому структуру Plasma.

Одним з ключових уявлень є те, що система Plasma не потребує ідеальності. Навіть якщо ви можете захистити лише підмножину активів (наприклад, лише Токен, який не рухався протягом останнього тижня), ви вже значно поліпшили поточний стан супермасштабованої EVM (тобто Validium).

Ще один тип структури - це змішана Plasma/Rollup, наприклад Intmax. Ці конструкції поміщають невеликий обсяг даних кожного користувача у блокчейн (наприклад, 5 байтів), що дозволяє отримати деякі особливості між Plasma і Rollup: у випадку Intmax ви можете отримати високу масштабованість та приватність, хоча, в теорії, обмежена до приблизно 266, 667 TPS навіть у вмісті обсягом 16 МБ.

Які посилання існують на відповідні дослідження?

• Оригінальна Plasma paper:
• Плазмова готівка:
• Грошовий потік плазми:
• Intmax ( 2023):

Що ще потрібно зробити? Які узгодження?

Основне завдання, що залишилося, - запустити плазмову систему у виробництво. Як згадувалося вище, Плазма проти Validium "не є вибором або/або: будь-який валідіум може покращити свої атрибути безпеки, принаймні до певної міри, шляхом включення функцій Плазми до механізму виходу. Основна увага дослідження зосереджена на отриманні найкращих атрибутів для EVM (з точки зору вимог до довіри, найгірших витрат на газ L1 та здатності протистояти DoS-атакам), а також альтернативних архітектур для конкретних додатків. Крім того, Плазма концептуально складніша за Rollup, яку потрібно вирішувати безпосередньо шляхом дослідження та створення кращої загальної структури.

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

Як взаємодіяти з іншими частинами дорожньої карти?

Чим ефективніше розроблена рішення Plasma, тим менше тиску на L1 з його високопродуктивними можливостями доступу до даних. Перенесення активності на L2 також допомагає зменшити тиск на L1 від MEV.

Зрілий L2 системи підтвердження

Ми вирішуємо яку проблему?

Наразі більшість Rollup фактично не є ненадійними. Існує комітет з безпеки, який має здатність перевизначити поведінку системи довірчих доказів (оптимістичних або валідних). У деяких випадках система доказів навіть не працює взагалі або має лише функцію «консультування». Найпрогресивніші Rollup включають: (i) деякі застосовувані специфічні Rollup, такі як FUEL; (ii) на даний момент часу Optimism і Arbitrum - два повноцінних EVM Rollup, які реалізували перший етап безпечного віддаленого виконання без необхідності довіри. Причина, чому Rollup не зробив більшого прогресу, полягає в тому, що хвилюються наявність помилок у коді. Нам потрібен ненадійний Rollup, тому нам потрібно прямо стикатися з цією проблемою та вирішувати її.

Що це таке і як воно працює?

Спочатку давайте згадаємо систему «stage», яка була введена в цій статті.

Етап 0: користувач повинен мати змогу запустити Нода та синхронізувати ланцюг. Якщо перевірка є повністю надійною / централізованою, то це не має значення.

Етап 1: Повинна бути наявна (недовірена) система доказів, щоб гарантувати, що будуть прийматися лише дійсні операції. Дозволяється наявність комісії безпеки, яка може скасувати систему доказів, але для цього потрібно голосування з 75% порогом. Крім того, частина комісії, яка блокує кворум (тобто 26% +), повинна бути поза головною компанією, що створює Rollup. Дозволяється використання менш потужного механізму оновлення (наприклад, DAO), але він повинен мати достатньо довгу затримку, щоб користувачі могли вивести свої кошти, якщо схвалено зловмисне оновлення, до того, як кошти будуть доступні.

Етап 2: повинна бути (недовірена) система підтвердження, щоб гарантувати, що будуть прийняті лише дійсні угоди. Комісія з безпеки дозволяє втручатися лише у випадку підтверджених помилок у коді, наприклад, якщо дві надлишкові системи підтвердження не узгоджуються між собою або якщо одна система підтвердження приймає два різних post-state корені одного й того ж Блоку (або не приймає жодного вмісту протягом достатньо довгого часу, наприклад, тиждень). Дозволяється використання механізму оновлення, але з великою затримкою.

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

• Формальна верифікація: ми можемо використовувати сучасну математику та обчислювальну техніку, щоб довести (оптимістичний та валідний) доказ системи, яка приймає лише ті Блоки, які відповідають специфікації EVM. Ці техніки існують вже десятки років, але останні досягнення (наприклад, Lean 4) роблять їх більш практичними, а досягнення у сфері AI-підтриманого доведення можуть подальш прискорити цей тренд.
• Багатодоказові (Multi-provers): створення кількох систем доказів та вкладення коштів у ці системи доказів разом із комісією безпеки (або іншими довіреними інструментами, такими як TEE, що мають деякі довірилові припущення). Якщо системи доказів погоджуються, комісія безпеки не має влади; якщо вони не погоджуються, комісія безпеки може лише вибирати між ними, вона не може односторонньо нав’язувати свою відповідь.

Програмний графік багатоактивістів, що поєднує оптимістичну систему доказу, систему доказу дійсності та комісію з безпеки.

Які посилання є на існуючі дослідження?

• Семантика EVM K (формальна верифікація з 2017 року):
• Про лекцію про багатофакторний підхід (2022):
• Taiko планує використовувати багатократне підтвердження:

Що ще потрібно зробити? Які узгодження?

Для Формальна верифікація, робота велика. Нам потрібно створити формально підтверджену версію SNARK-професора для всієї Віртуальна машина Ethereum. Це дуже складний проект, хоча ми вже почали його. Є один хитрість, яка значно спрощує це завдання: ми можемо створити формально підтвердженого SNARK-професора для мінімальної Віртуальна машина (наприклад, RISC-V або Cairo), а потім реалізувати EVM в цій мінімальній Віртуальна машина (і формально підтвердити його еквівалентність з іншими ETH-блокчейн Віртуальна машина специфікаціями).

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

Як взаємодіяти з іншими частинами дорожньої карти?

Перенесення події на L2 може зменшити тиск MEV на L1.

Покращення між L2 взаємодії

Ми вирішуємо яку проблему?

Одним з головних викликів, які стикається екосистема L2 сьогодні, є складність навігації користувачів у ній. Крім того, найбільш прості шляхи часто повертаються до припущень про довіру: централізована крос-ланцюгова взаємодія, клієнти RPC тощо. Ми повинні зробити використання екосистеми L2 таким самим, як користування єдиним екосистемою Ethereum.

Що це таке? Як воно працює?

Покращення інтероперабельності між L2 має багато категорій. Теоретично, ETH-краплі, спрямовані на розвиток, і виконання Шардинг L1 - це одна і та ж річ. Проте на практиці екосистема ETH-краплі L2 має такі недоліки порівняно з ідеальним станом:

1. Адреса конкретного ланцюга: Адреса повинна містити інформацію про ланцюг (L1, Optimism, Arbitrum …). Як тільки це буде досягнуто, ви зможете просто вставити Адреса в поле “Надіслати” для здійснення процесу надсилання через L2, при цьому Гаманець може самостійно обробляти, як надсилати (включаючи використання крос-ланцюжногопротоколу).

2. Запит на оплату на конкретному ланцюжку: повинен бути легко та стандартизовано створювати повідомлення у формі “надішліть мені X одиниць токену Y на ланцюжку Z”. Це основним чином застосовується в двох випадках: (i) оплата між людьми або між людиною та сервісом продавця; (ii) запит DApp на фінансування.

3. Взаємодія міжланцюжкового обміну та оплати газу: має бути стандартизований відкритий протокол для вираження операцій міжланцюжкової взаємодії, таких як «Я надішлю 1 ефір (на Optimism), тому що мені було надіслано 0,9999 ефіру на Arbitrum» та «Я надішлю 0,0001 ефіру (на Optimism) тому, хто включив цю транзакцію на Arbitrum». ERC-7683 спроба стандартизувати першу операцію, а RIP-7755 - другу, хоча їх застосування ширше, ніж ці конкретні випадки.

4、легкий клієнт：користувач повинен мати змогу фактично перевірити ланцюг, з яким вони взаємодіють, а не просто довіряти постачальнику RPC. Helios від a16z crypto може зробити це (для самого ETH), але нам потрібно розширити цю довіру до L2. ERC-3668 (CCIP-read) - це одна з стратегій для досягнення цієї мети.

Як оновити перегляд ланцюжка заголовків Ethereum для легкого клієнта. Після того, як у вас є ланцюжок заголовків, ви можете використовувати доведення Меркла, щоб перевірити будь-який об’єкт стану. Як тільки у вас є правильний об’єкт стану L1, ви можете використовувати доведення Меркла (якщо ви хочете перевірити передплату, ви також можете використовувати підпис), щоб перевірити будь-який об’єкт стану на L2. Helios вже зробив перше. Розширення до останнього є стандартизаційним викликом.

1、Keystore Гаманець: зараз, якщо ви хочете оновити Секретний ключ вашого Смарт-контракту Гаманця, який контролюється, ви повинні оновити його на всіх N-ланцюгах, на яких існує цей Гаманець. Keystore Гаманець - це технологія, яка дозволяє Секретному ключу існувати тільки в одному місці (або на L1, або, можливо, на L2 в майбутньому), і будь-який L2, що має копію Гаманця, може читати Секретний ключ з нього. Це означає, що оновлення потрібно проводити тільки один раз. Щоб забезпечити ефективність, Keystore Гаманець вимагає, щоб у L2 був стандартизований спосіб безкоштовного читання інформації з L1; для цього є два пропозиції - L1S LOAD і REMOTESTATICCALL.

Принцип роботи Гаманця Keystore

2、Більш радикальна концепція «моста для спільного Токен»: уявіть собі світ, де всі L2 є доказ дійсності Rollup, і кожен слот подається в ETH блоці. Навіть у такому світі перенесення активів з одного L2 в інший L2 в їхньому первинному стані все ще потребує зняття та внесення депозиту, що вимагає великої кількості L1 газової плати. Один із способів вирішення цієї проблеми - створення спільного простого Rollup, що має єдину функцію - відстежувати, який L2 володіє кожним типом Токену та скільки балансів у них є, і дозволяти цим балансам оновлюватися пакетами через послідовні операції, запущені будь-яким L2. Це дозволить здійснювати перекази між L2 без необхідності сплачувати L1 газову плату за кожен переказ, а також без використання технологій на базі постачальників ліквідності, таких як ERC-7683.

3. Синхронізація комбінування: дозволяє здійснювати синхронні виклики між певним L2 та L1 або між кількома L2. Це сприяє підвищенню фінансової ефективності протоколу Децентралізовані фінанси. Перше може бути досягнуто без будь-якої координації між L2, а друге потребує спільного сортування. Технологія, заснована на Rollup, автоматично застосовується до всіх цих технологій.

Які посилання є на існуючі дослідження?

Ланцюжок адреса：

ERC-3770 :

ERC-7683:

РІП-7755:

Scroll keystore дизайн Гаманець:

Геліос:

ERC-3668 (іноді відомий як CCIP читання):

Пропозиція Джастина Дрейка щодо «попереднього підтвердження на основі (спільного)»:

L1S LOAD (RIP-7728): load-precompile/20388

REMOTESTATICCALL в Оптимизмі:

AggLayer, що включає в себе ідею спільного моста токенів:

Що ще потрібно зробити? Які узгодження?

Багато прикладів, наведених вище, стикаються з проблемою стандартизації - коли і які рівні слід стандартизувати. Якщо стандартизувати занадто рано, це може закріпити менш ефективне рішення. Якщо стандартизувати занадто пізно, може виникнути непотрібна фрагментація. У деяких випадках існує тимчасове рішення з менш сприятливими характеристиками, але легше впроваджувати, а також довгострокове рішення “остаточно правильне”, яке потребує кілька років для реалізації.

Ці завдання - не тільки технічні проблеми, вони також є (і можливо, головним чином) соціальними проблемами, які вимагають співпраці L2 і Гаманець, а також L1.

Як взаємодіяти з іншими частинами дорожньої карти?

Більшість пропозицій в цих пропозиціях є структурами «вищого рівня», тому вони майже не впливають на розгляд на рівні L1. Одним з винятків є спільне сортування, яке має значний вплив на максимальну вартість, що видобувається (MEV).

Розширення виконання на L1

Ми вирішуємо яку проблему?

Якщо L2 стає дуже масштабованим і успішним, але L1 все ще може обробляти дуже мало об’єму, то Ethereum може зіткнутися з багатьма ризиками:

1. Економічний стан активів ETH стане ще більш нестабільним, що, в свою чергу, вплине на довгострокову безпеку мережі.

2. Багато L2 виграють від тісного зв’язку з розвинутою фінансовою екосистемою на L1. Якщо ця екосистема значно послаблюється, то стимули до переходу на L2 (замість того, щоб стати самостійним L1) будуть меншими.

3, L2 потребує дуже багато часу, щоб досягти повної безпеки, ідентичної L1.

4. Якщо L2 зазнає невдачі (наприклад, через зловживання або зникнення оператора), користувач все ще потребує відновити свої активи через L1. Тому L1 повинен бути достатньо потужним, щоб здатися в деяких випадках реально опрацювати складні та хаотичні завершальні роботи L2.

З цих причин дуже цінно продовжувати розширення самої L1 та забезпечити її здатність далі вміщувати все більше використань.

Що це таке? Як це працює?

Найпростіший спосіб розширення полягає в прямому збільшенні ліміту газу. Однак це може призвести до централізації L1, що знижує надійність ETH як сильного основного рівня. Щодо того, наскільки сталий є просте збільшення ліміту газу, існує суперечка, і це буде залежати від того, які інші технології будуть впроваджені для полегшення перевірки більших блоків (наприклад, прострочення історії, безстатусність, доказ дійсності L1 EVM). Ще одним важливим аспектом, який потребує постійного вдосконалення, є ефективність клієнтського програмного забезпечення ETH, яка на сьогоднішній день значно вища, ніж п’ять років тому. Ефективна стратегія збільшення ліміту газу L1 включатиме прискорення розвитку цих технологій перевірки.

• EOF: новий формат байткоду EVM, більш дружній до статичного аналізу, що дозволяє досягти швидшого виконання. З урахуванням цих покращень ефективності, байткод EOF може забезпечити менші витрати на газ.
• Багатовимірна оцінка газу: встановлення різних основних витрат та обмежень для обчислення, даних та зберігання, що дозволяє збільшити середню потужність ETH L1 без збільшення максимальної ємності (тим самим уникнути нових ризиків безпеки).
• Падіння певних опкодів та вартості газу для попереднього компілювання - історично ми декілька разів збільшували вартість газу для деяких опкодів, що мали занадто низьку ціну, щоб уникнути атак на відмову в обслуговуванні. Ще більше можна зробити, зменшивши вартість газу для опкодів з завищеною ціною. Наприклад, додавання набагато дешевше множення, але наразі вартість опкодів ADD і MUL однакова. Ми можемо знизити вартість ADD навіть нижче і зробити ще дешевшою вартість опкодів, наприклад, PUSH. Загалом, це є напрямком оптимізації в EOF.
• EVM-MAX і SIMD: EVM-MAX - це пропозиція, яка дозволяє більш ефективні обчислення великих нативних чисел як окремий модуль EVM. Якщо не зазначено інше, значення, обчислені EVM-MAX, можуть бути доступні тільки іншим опкодам EVM-MAX. Це дозволяє більшу гнучкість у форматі зберігання цих значень. SIMD (однократна інструкція, кілька даних) - це пропозиція, яка дозволяє ефективно виконувати однакові інструкції для масивів значень. Разом вони можуть створити потужний ко-процесор поруч з EVM, який може бути використаний для більш ефективної реалізаціїшифрування операцій. Це особливо корисно для протоколів конфіденційності та систем захисту L2, тому це сприятиме розширенню L1 та L2.

Ці поліпшення будуть детальніше розглянуті в майбутніх статтях Splurge.

Нарешті, третя стратегія - це вбудовані Rollups (або устатковані роллапи): в сутності, створення багатьох паралельних робочих копій EVM, щоб створити модель, яка є еквівалентною тому, що може надати Rollup, але більш інтегрована у протокол.

Які посилання є на існуючі дослідження?

• Маршрутна карта розширення L1 Polynya для ETH
• Багатовимірна ціна на газ:
• EIP-7706:
• У порівн.
• EVM-MAX:
• У порівн.
• Native роллапи:
• Макс Резник розмовляє про цінність розширення L1 у своєму інтерв’ю:
• Джастін Дрейк розмовляє про розширення за допомогою SNARK та первісних роллапів:

Що ще потрібно зробити, які компроміси?

Розширення L1 має три стратегії, які можна виконувати окремо або паралельно:

• Покращення технічних засобів (наприклад, клієнтський код, безстанційний клієнт, застарілість історії) для полегшення перевірки L1, а потім підвищення обмеження газу.
• Скорочення вартості певних операцій, збільшення середньої потужності без збільшення ризику найгіршого випадку;
• Оригінальні роллапи (тобто створення N паралельних копій EVM).

Розуміючи ці різні технології, ми побачимо, що кожна має свої власні компроміси. Наприклад, у нативних роллапах є багато тих самих слабких місць у комбінаторному плані, як і в звичайних роллапах: ви не можете надіслати одну операцію, яка виконується через кілька роллапів, так само, як ви можете зробити це в контракті на тому ж L1 (або L2). Збільшення верхнього ліміту газу зменшить інші переваги, які можуть бути досягнуті за допомогою спрощеної перевірки на L1, такі як збільшення кількості користувачів, які виконують перевірку Нода, та збільшення кількості solo стейкерів. Залежно від способу реалізації, зробити певні операції у Віртуальній машині Ethereum (EVM) дешевшими може збільшити загальну складність EVM.

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

Погляд на розділ праці між L1 та L2

Як взаємодіяти з іншими частинами дорожньої карти?

Залучення більшої кількості користувачів до L1 означає не тільки покращення масштабування, але й покращення інших аспектів L1. Це означає, що більше MEV залишиться на L1 (а не стане проблемою лише L2), тому потреба чітко вирішувати проблему MEV стане ще більш нагальною. Це значно підвищить цінність швидкого слот-часу на L1. Водночас це також сильно залежить від успішного проведення валідації на L1 (Verge).