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

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

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

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

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

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

Прилив: Ключова мета

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

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

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

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

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

1. Трійка парадоксу масштабованості

2. Подальший прогрес у вибірковій доступності даних

3.стиснення даних

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

5.зрілі системи підтвердження L2

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

7.розширення виконання на рівні 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 кБ на кожен слот. Припустимо, що дані транзакції публікуються безпосередньо в у блокчейні, тоді максимальна TPS Rollup на ETH-ланцюжку становитиме: 375000 / 12 / 180 = 173,6 TPS

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

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

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

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

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

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

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

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

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

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

Які зв’язки є з існуючими дослідженнями?

1. Первоначальное сообщение о доступности данных (2018):

2.Слідуючий папір:

3. Про пояснення DAS, парадигма:

4. Доступність 2D з обіцянкою KZG:

5.ethresear.ch на PeerDAS: та документ:

6. EIP-7594:

SubnetDAS на 7.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.（Hard pivot）відмовитися від DA, повністю прийняти Plasma як основну архітектуру нашого Layer2.

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

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

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

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

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

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

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 вей. Максимальна базова комісія та пріоритетна комісія також подібні. Тому ми можемо використовувати власний десятковий формат з плаваючою точкою для відображення більшості валютних значень.

Які зв’язки є з існуючими дослідженнями?

1. Дослідження послідовності.xyz:

2. Оптимізація контракту L2 Calldata:

3. Засновані на доказі дійсності роллапи (також відомі як ZK роллапи) випускаються з різницею стану, а не транзакціями:

4. Гаманець BLS - Реалізація агрегації BLS через ERC-4337:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Які посилання є наразі пов’язані з наявними дослідженнями?

1.Оригінальна стаття про плазму:

2. Плазма Кеш:

3. Потік грошей з плазмою:

4. Intmax (2023):

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

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

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

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

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

Зріла система доказів L2

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

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

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

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

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

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

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

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

1.Формальна верифікація：мы можем використовувати сучасну математику та обчислювальну техніку для підтвердження (оптимістичний та валідний) системи доведення тільки приймає блоки, які відповідають специфікації EVM. Ці техніки існують вже десятки років, але останні досягнення (наприклад, Lean 4) роблять їх більш практичними, а прогрес у сфері AI-підтримуваних доведень може подальшим чином прискорити цю тенденцію.

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

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

Які зв’язки є з існуючими дослідженнями?

1. EVM K Семантика (формальная верификация работы с 2017 года):

2.Про презентацію багатодоказової концепції (2022):

3. Планується використати багатократне підтвердження:

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

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

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

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

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

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

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

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

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

Існує багато категорій для поліпшення між L2. Теоретично, ETH-блокчейн на базі 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-читання) - це стратегія для досягнення цієї мети.

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

1. Keystore Гаманець: зараз, якщо ви хочете оновити контроль за вашим Смарт-контрактом Гаманцем зі секретним ключем, вам потрібно буде оновити його на всіх N ланцюгах, на яких існує цей Гаманець. Keystore Гаманець - це технологія, яка дозволяє секретному ключу існувати лише в одному місці (або на L1, або, можливо, в майбутньому на L2), після чого будь-який L2, який має копію Гаманця, може читати секретний ключ. Це означає, що оновлення потрібно провести лише один раз. Для підвищення ефективності Keystore Гаманця вимагає, щоб у 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 автоматично застосовується до всіх цих технологій.

Які зв’язки є з існуючими дослідженнями?

1. Спеціальна адреса ланцюга: ERC-3770:

2. ERC-7683:

3. РІП-7755:

4. Прокрутіть гаманець дизайну ключового сховища:

5. Геліос:

6. ERC-3668 (іноді його називають CCIP):

7. Пропозиція Джастіна Дрейка «Заснована на (спільному) попередньому підтвердженні»:

8.L1SLOAD (РІП-7728):

9.REMOTESTATICCALL в оптимізмі:

10. 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. Багатовимірне ціноутворення газу: встановлення різних основних витрат і обмежень для обчислень, даних та збереження, які дозволяють збільшити середню місткість L1 Ethereum без збільшення максимальної місткості (таким чином уникнути виникнення нових ризиків безпеки).

3. Падіння вартості конкретного опкоду та попереднього газу - З історичної перспективи, для запобігання атак на відмову в обслуговуванні, ми кілька разів збільшували вартість газу для деяких опкодів з низькою ціною. Ще одним кроком може бути зниження вартості газу для опкодів з високою ціною. Наприклад, додавання коштує набагато менше, ніж множення, але в даний час вартість опкодів ADD і MUL однакова. Ми можемо знизити вартість ADD і навіть зробити дещо простіші опкоди, такі як PUSH, дешевшими. Загалом, EOF в цьому відношенні є більш оптимізованим.

4. EVM-MAX та SIMD: EVM-MAX - це пропозиція, яка дозволяє більш ефективно використовувати нативні великі числа як окремий модуль EVM. Числові значення, обчислені за допомогою EVM-MAX, можуть бути доступні тільки для інших операцій EVM-MAX, якщо не зазначено інше. Це дозволяє зберігати ці значення в оптимізованому форматі. SIMD (однократна інструкція, багато даних) - це пропозиція, яка дозволяє ефективно виконувати однакові інструкції для масиву значень. Разом вони можуть створити потужний копроцесор поряд з EVM, що може бути використаний для більш ефективної реалізаціїшифрування операцій. Це особливо корисно для протоколів конфіденційності та систем захисту L2, тому це сприятиме розширенню L1 та L2.

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

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

Які зв’язки є з існуючими дослідженнями?

1. Roadmap розширення L1 Polynya ETH:

2. багатовимірне ціноутворення газу:

3. EIP-7706:

4. EOF:

5. EVM-MAX:

6. SIMD:

7. Native роллапи:

8.Max Resnick інтерв’ю з важливістю розширення L1

9. Джастін Дрейк розмовляє про використання SNARK та примітивних роллапів для масштабування:

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

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

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

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

3. Оригінальні роллапи (тобто, створення N паралельних копій ЕVM).

Розуміючи ці різні технології, ми побачимо, що вони мають різні компроміси. Наприклад, у стандартних Rollups є багато слабких місць у питанні комбінування: ви не можете відправити одну транзакцію, щоб синхронізувати операції на кількох Rollup, так само, як ви можете зробити це в контракті на одному 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).

Пов’язане читання: «Нова стаття Віталіка: де ще можна покращити PoS ETH? Як це зробити?»

Посилання на оригінальний текст