Нове від Віталіка: Можливе майбутнє ETH, The Surge

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

Компіляція: Карен, Foresight News

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

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

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

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

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

Підйом: Ключові цілі

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

2. Збереження Децентралізації та стійкості L1.

3. Принаймні деякі L2 повністю успадковують ключові властивості Ethereum (ненадійний, відкритий, стійкий до цензури);

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

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

1. Трійковий парадокс масштабованості
2. Подальший прогрес у вибірковій доступності даних
3. Компресія даних
4. Загальний Плазма
5. Зрілі системи доведення L2
6. Покращення між L2 взаємодії
7. Розширення виконання на L1

Парадокс трьох протилежностей розширюваності

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

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

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

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

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

Додаткові покращення в зразках доступності даних

Що саме ми вирішуємо?

У 13 березня 2024 року, коли Dencun оновиться, на блокчейні ETH2.0 кожен слот триватиме 12 секунд, і буде містити 3 блоки розміром близько 125 кБ, або приблизно 375 кБ доступної пропускної здатності на кожен слот. Якщо дані транзакцій публікуються безпосередньо на у блокчейні, то перекази ERC20 складуть близько 180 байт, тому максимальна швидкість обробки транзакцій (TPS) на Rollup у мережі ETH2.0 становитиме: 375000 / 12 / 180 = 173.6 TPS

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

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

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

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

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

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

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

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

2D вибірка. Джерело: a16z криптовалюта

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

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

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

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

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

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

Мені здається, що довгострокова реальна траєкторія полягає в наступному:

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

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

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

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

Стиснення даних

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

На мою думку, найкращим поясненням є ця картинка два роки тому:

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

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

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

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

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

1. Досліджуйте sequence.xyz:
2. Оптимізація контракту L2 Calldata:
3. Rollups на основі доказу дійсності (також відомі як ZK роллапи) відрізняються від стану публікації, а не від транзакції:
4. Гаманець BLS - реалізація BLS-агрегації через ERC-4337:

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

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

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

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

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 (не єдиний спосіб): використання ZK-SNARK для побудови паралельного дерева UTXO, яке відображає зміни балансу, здійснені EVM, та визначає єдине відображення «Токен» на різних часових точках в історії. Потім можна побудувати на ньому структуру Plasma.

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

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

Існують посилання на пов’язані дослідження?

1. Оригінальна Plasma-стаття:
2. Плазмова готівка:
3. Потік готівки Plasma Cashflow:
4. Intmax (2023):

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

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

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

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

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

Зріла система доведення L2

Що саме ми вирішуємо?

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

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

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

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

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

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

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

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

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

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

1. Семантика EVM K (формальна верифікація роботи з 2017 року):
2. Про промову про багатофакторну думку (2022):
3. Taiko планує використовувати мультипруф:

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

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

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

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

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

Покращення міжопераційної сумісності між L2

Що саме ми вирішуємо?

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

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

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

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

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

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

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

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

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

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

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

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

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

**Специфічна адреса ланцюжка: ERC-3770:

**ERC-7683:

**RIP-7755:

**Дизайн Гаманця Scroll keystore:

**Геліос:

**ERC-3668 (іноді відомий як CCIP Read):

**Пропозиція Джастина Дрейка щодо “підтвердження на основі (спільного) попередньої угоди”:

**L1SLOAD (РІП-7728):

**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, що в свою чергу може підірвати іншу важливу характеристику Ethereum L1 - довіру як стійке основне рівень. Її стабільність. Щодо того, наскільки стійким є просте збільшення верхньої межі газу, досі існує розбіжність думок, і це також буде залежати від того, які саме технології будуть впроваджені для полегшення перевірки більших блоків (наприклад, простроченість, безстатевість, доказ дійсності L1 EVM). Ще одне важливе питання, яке потребує постійного вдосконалення, - це ефективність клієнтського програмного забезпечення Ethereum, яка зараз в набагато більшій мірі ефективна, ніж п’ять років тому. Ефективна стратегія збільшення верхньої межі газу L1 буде включати прискорення розвитку цих технологій перевірки.

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

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

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

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

1. Карта розширення шару L1 Ethereum Polynya:
2. Багатовимірне ціноутворення газу:
3. EIP-7706:
4. ЕОФ:
5. ЕВМ-МАКС:
6. SIMD:
7. Native роллапи:
8. Макс Резник в інтерв’ю про цінність розширення L1:
9. Джастін Дрейк говорить про розширення за допомогою SNARK та оригінальних роллапів:

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

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

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

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

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

Один погляд на розподіл роботи між L1 та L2

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

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

Рекомендовано до читання: “Нова стаття Віталіка: Майбутнє можливого об’єднання ETH”