На початку у Ethereum було дві стратегії масштабування в своєму плані. Одна (наприклад, див. цей ранній документз 2015 року) було «розщеплення»: замість перевірки та зберігання всіх транзакцій у ланцюжку, кожен вузол повинен був би перевірити й зберегти лише невелику частину транзакцій. Це працює так само, як будь-яка інша мережа однорідних вузлів (наприклад, BitTorrent), отже, безумовно, ми змогли б зробити блокчейни працюючими таким чином. Іншою була протоколи рівня 2: мережі, які мали би бути розташовані поверх Ethereum таким чином, щоб дозволити їм повністю скористатися його безпекою, утримуючи при цьому більшість даних та обчислень поза основним ланцюжком. «Протоколи рівня 2» означаликанали стануу 2015 році,Плазмау 2017 році, а потімrollupsу 2019 році. Роллапи потужніше, ніж канали стану або Плазма, але вони потребують великої кількості ширини смуги даних on-chain. На щастя, до 2019 року дослідження шарування вирішилипроблема підтвердження «доступності даних» в масштабіВ результаті обидві шляхи зійшлися, і ми отримали дорожній карті rollupяка і далі залишається стратегією масштабування Ethereum сьогодні.

The Surge, видання дорожньої карти 2023 року.

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

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

Спалах: ключові цілі

• 100 000+ TPS на L1+L2
• Зберігайте децентралізацію та надійність L1
• Принаймні деякі L2 повністю успадковують основні властивості Ethereum (без довіри, відкриті, стійкі до цензури)
• Максимальна взаємодія між L2. Ethereum повинен відчуватися як єдина екосистема, а не 34 різних блокчейни.

У цій главі

• Окрім того: трилема масштабованості
• Додатковий прогрес у вибірці доступності даних
• Стиснення даних
• Узагальнена Плазма
• Досягнення систем доказів рівня L2
• Міжплатформена сумісність L2 та покращення UX
• Масштабування виконання на рівні L1

Окрім того: трилема масштабованості

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

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

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

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

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

Додатковий прогрес у вибірці доступності даних

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

As of 2024 March 13, when the Оновлення Dencunпішов у живе, у блокчейні Ethereum є три ~125 кБ «блоби» на кожен 12-секундний слот, або ~375 кБ на слот для пропускної здатності для доступності даних. З урахуванням того, що дані транзакцій публікуються безпосередньо на ланцюгу блоків, переказ ERC20 становить ~180 байтів, тому максимальна TPS роллапів на Ethereum становить:

375000 / 12 / 180 = 173.6 TPS

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

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

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

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

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

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

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

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

Важливо, обчислення розширення зобов'язань не потребує наявності блобів, тому схема фундаментально дружня до розподіленої побудови блоків. Вузол, який фактично будує блок, повинен мати лише зобов'язання KZG blob та може покладатися на DAS для перевірки доступності блобів. 1D DAS також має вбудовану дружність до розподіленої побудови блоків.

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

• Оригінальний пост, що представляє доступність даних (2018 р.): https://github.com/ethereum/research/wiki/Примітка-щодо-доступності-даних-та-кодування-стерилізації
• Доповідь з подальшим викладом: https://arxiv.org/abs/1809.09044
• Пояснювальний пост про DAS, парадигма: https://www.paradigm.xyz/2022/08/das
• Наявність 2D з зобов'язаннями KZG: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
• PeerDAS на ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 , і папір: https://eprint.iacr.org/2024/1362
• Презентація про PeerDAS від Франческо: https://www.youtube.com/watch?v=WOdpO1tH_Us
• EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
• SubnetDAS на ethresear.ch: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
• Відтінки відновлення в 2D вибірці: https://ethresear.ch/t/відтінки-відновленості-даних-при-вибірковому-доступі-до-даних/16256

Що залишилося робити, і які компроміси?

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

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

Реалістичні шляхи, які я бачу на довгу перспективу, -

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

Ми можемо переглянути це вздовж спектру компромісів:

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

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

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

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

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

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

16000000 / 12 / 180 = 7407 TPS

Що, крім роботи з чисельником, якщо ми зможемо працювати з знаменником, і зробити кожну транзакцію в роллапі меншою за обсягом на ланцюжку?

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

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

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

• Агрегація підписів - ми переходимо від підписів ECDSA до підписів BLS, які мають властивість того, що багато підписів можна об'єднати в один підпис, який підтверджує дійсність всіх початкових підписів. Це не розглядається для L1, оскільки обчислювальні витрати для верифікації, навіть з агрегацією, вищі, але в середовищі з обмеженими даними, наприклад, у L2, вони, за усіма показаннями, мають сенс. Функція агрегації ERC-4337представляє один шлях для впровадження цього.
• Заміна адрес за допомогою покажчиків - якщо адресу вже використано, ми можемо замінити 20-байтову адресу 4-байтовим покажчиком на місце в історії. Це потрібно для досягнення найбільших виграшів, хоча для його впровадження потрібно зусиль, оскільки це вимагає (принаймні частини) історію блокчейну ефективно стати частиною стану.
• Користувацька серіалізація для значень транзакцій - більшість значень транзакцій мають дуже мало цифр, наприклад, 0.25 ETH представлено як 250,000,000,000,000,000 вей. Максимальні базові коефіцієнти газу та пріоритетні винагороди працюють аналогічно. Таким чином, ми можемо дуже компактно представляти більшість валютних значень за допомогою користувацького десяткового формату з плаваючою комою або навіть словника особливо поширених значень.

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

• Дослідження з sequence.xyz: https://sequence.xyz/blog/compressing-calldata
• Оптимізовані дані виклику контрактів для L2s, від ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• Альтернативна стратегія - докази валідності на основі ролапів (так званих ZK ролапів) публікують різниці в стані замість транзакцій: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
• BLS гаманець - реалізація агрегування BLS через ERC-4337: https://github.com/getwax/bls-wallet

Що залишилося робити, і які компроміси?

Основне, що залишилося зробити, - це фактичне впровадження вищезазначених схем. Основні компроміси:

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

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

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

Узагальнена Плазма

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

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

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

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

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

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

Один спосіб (не єдиний спосіб) створити ланцюжок плазми EVM: використовуйте ZK-SNARK для побудови паралельного дерева UTXO, яке відображає зміни балансу, зроблені EVM, і визначає унікальне відображення того, що є "тією ж монетою" в різні історичні моменти. Плазмова конструкція може бути побудована на цьому підґрунті.

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

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

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

• Оригінальна стаття про плазму: https://plasma.io/plasma-deprecated.pdf
• Плазма Кеш: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
• Грошовий потік у плазмі: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Вихід
• Intmax (2023): https://eprint.iacr.org/2023/1082

Що залишилося зробити, і які компроміси?

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

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

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

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

Удосконалення L2 систем доказів

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

Сьогодні більшість ролапів ще не є дійсно надійними; є рада з безпеки, яка має можливість перекрити поведінку (оптимістичну чи валідність)система доказівУ деяких випадках система доказів взагалі не працює, або, якщо вона працює, має лише «консультативну» функціональність. Найдалі вперед є (і) кілька спеціалізованих rollups, таких як Fuel, які є безпечними, і (іі) на момент написання цього Optimism і Arbitrum, два повноцінних rollups EVM, які досягли часткового рівня безпеки, відомого як «етап 1». Причина, чому rollups не продовжують розвиватися, - це стурбованість помилками в коді. Нам потрібні безпечні rollups, тому нам потрібно вирішити цю проблему напряму.

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

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

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

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

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

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

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

• EVM K Semantics (формальна верифікація роботи з 2017 року): https://github.com/runtimeverification/evm-semantics
• Презентація про ідею мультидоказів (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
• Тайко планує використовувати мультипруф: https://docs.taiko.xyz/core-concepts/multi-proofs/

Що залишилося робити, і які компроміси?

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

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

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

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

Удосконалення сумісності між L2

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

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

Приклад патологічно поганого (і навіть небезпечного: я особисто втратив $100 через помилку вибору ланцюга тут) UX між L2 - хоча це не вина Polymarket, міжланцюжкова сумісність повинна бути відповідальністю гаманців та спільноти стандартів Ethereum (ERC). У добре функціонуючому екосистемі Ethereum, відправка монет з L1 на L2 або з одного L2 на інший повинна відчуватися так само, як і відправка монет у межах одного L1.

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

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

• Адреси, специфічні для ланцюжка: ланцюжок (L1, Optimism, Arbitrum...) має бути частиною адреси. Після того, як це буде реалізовано, потоки надсилання між L2 можуть бути реалізовані, просто ввівши адресу в поле "send", після чого гаманець може з'ясувати, як зробити надсилання (включаючи використання протоколів мосту) у фоновому режимі.
• Запити на оплату для конкретного ланцюжка: повинно бути легко і стандартизовано створити повідомлення у формі "надішліть мені X токенів типу Y на ланцюжку Z". Це має два основні використання: (i) платежі, незалежно від того, чи це особа до особи, чи особа до послуги-торговця, і (ii) додатки, які звертаються за коштами, наприклад, зазначений вище приклад Polymarket.
• Атомарний обмін між ланцюжками та оплата газу: повинен існувати стандартизований відкритий протокол для вираження операцій між ланцюжками, таких як «Я відправляю 1 ETH на Optimism кому-небудь, хто відправить мені 0.9999 ETH на Arbitrum», і «Я відправляю 0.0001 ETH на Optimism кому-небудь, хто включить цю транзакцію на Arbitrum».ERC-7683це одна спроба колишнього, а RIP-7755це одна спроба в останньому, хоча обидва є також загальними, ніж лише ці конкретні випадки використання.
• Легкі клієнти: користувачі повинні мати змогу фактично перевіряти ланцюги, з якими вони взаємодіють, а не просто довіряти постачальникам RPC. A16z крипто Геліосце робить для самого Ethereum, але нам потрібно розширити цю недовіру до L2s.ERC-3668 (CCIP-read)це одна стратегія для цього.

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

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

Стилізована діаграма того, як працюють гаманці з ключами доступу.

• Більш радикальні ідеї «спільного мосту токенів»: уявіть собі світ, де всі L2 є зведеннями з перевіркою дійсності, які зобов'язуються використовувати Ethereum у кожному слоті. Навіть у цьому світі переміщення активів з одного L2 на інший L2 «нативно» вимагатиме зняття та депонування, що вимагає сплати значної кількості L1 газу. Одним із способів вирішити цю проблему є створення спільного мінімального зведення, єдиною функцією якого було б підтримувати баланси того, скільки токенів якого типу належить якому L2, і дозволяти масово оновлювати ці баланси за допомогою серії операцій перехресного надсилання L2, ініційованих будь-яким із L2. Це дозволило б здійснювати перехресні перекази L2 без необхідності платити газ L1 за переказ і без необхідності використання методів, заснованих на постачальниках ліквідності, таких як ERC-7683.
• Синхронна комбінуваність: дозволяє синхронним викликам відбуватися або між конкретним L2 та L1, або між кількома L2. Це може бути корисним для покращення фінансової ефективності протоколів defi. Перше може бути зроблено без будь-якої координації між L2; для останнього знадобитьсяСпільна послідовність дій. Основані ролапсиавтоматично дружні до всіх цих технік.

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

• Адреси, специфічні для ланцюга: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770
• ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
• RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
• Дизайн гаманця Scroll keystore: @haichen/keystore"">https://hackmd.io/@haichen/keystore
• Геліос:https://github.com/a16z/helios
• ERC-3668 (іноді називається CCIP-read): https://eips.ethereum.org/EIPS/eip-3668
• Пропозиція щодо "заснованих (спільних) попередніх підтверджень" від Джастіна Дрейка: https://ethresear.ch/t/based-preconfirmations/17353
• L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
• REMOTESTATICCALL в Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
• AggLayer, який включає ідеї спільного токен-мосту: https://github.com/AggLayer

Що залишилося робити, і які компроміси?

Багато з наведених вище прикладів стикаються зі стандартними дилемами: коли стандартизувати і які шари стандартизувати. Якщо ви стандартизуєте занадто рано, ви ризикуєте закріпити неповноцінне рішення. Якщо ви стандартизуєте занадто пізно, ви ризикуєте створити непотрібну фрагментацію. У деяких випадках існує як короткострокове рішення, яке має слабші властивості, але легше реалізується, так і довгострокове рішення, яке є «в кінцевому підсумку правильним», але для досягнення цього знадобиться досить багато років.

Одним зі способів, яким цей розділ є унікальним, є те, що ці завдання - це не просто технічні проблеми: вони також (можливо, навіть в першу чергу!) соціальні проблеми. Для їх вирішення потрібне співробітництво між L2s і гаманцями та 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 передбачала б прискорення цих технологій перевірки.

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

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

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

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

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

• Дорожня карта масштабування Ethereum L1 від Polynya: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
• Багатовимірна цінова політика на газ: https://vitalik.eth.limo/general/2024/05/09/multidim.html
• EIP-7706: https://eips.ethereum.org/EIPS/eip-7706
• EOF: https://evmobjectformat.org/
• EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
• SIMD: https://eips.ethereum.org/EIPS/eip-616
• Native rollups: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
• Інтерв'ю з Максом Ресніком про цінність масштабування L1: https://x.com/BanklessHQ/status/1831319419739361321
• Джастін Дрейк про використання SNARKs та внутрішні rollups для масштабування: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

Що залишилося робити, і які компроміси?

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

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

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

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

Одна запропонована точка зору щодо "розділу праці" між L1 та L2s,джерело.

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

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

Disclaimer：

1. Ця стаття перепечатана з [ Віталік Бутерін], Усі авторські права належать оригінальному автору [Віталік Бутерін]. Якщо є зауваження до цього перепублікування, будь ласка, зв'яжіться з Ворота Вчиться команди, і вони оперативно впораються з цим.
2. Повідомлення про відповідальність: Погляди та думки, висловлені в цій статті, є виключно власні автора та не становлять жодної інвестиційної поради.
3. Переклад статті на інші мови виконується командою Gate Learn. Якщо не вказано інше, копіювання, поширення або плагіат перекладених статей заборонено.