Майбутнє Ethereum: сплеск

Роудмап Ethereum спочатку містив дві стратегії масштабування: шардінг та протокол Layer2. Ці два шляхи врешті-решт злилися, утворивши роудмап, зосереджений на Rollup, який досі є поточною стратегією розширення Ethereum.

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

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

Підйом: ключова мета

1. У майбутньому Ethereum через L2 може досягти більше 100000 TPS;

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

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

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

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

1. Парадокс трикутника масштабованості
2. Подальший прогрес у вибірці доступності даних
3. Стиснення даних
4. Узагальнений Плазма
5. Досвідчена система доказів L2
6. Покращення крос-L2 інтероперабельності
7. Розширення виконання на L1

Парадокс трикутника масштабованості

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

! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск] (lab.com/yijian/2024/10/17/images/89c89d8561e79ae51787fbfee36ce211.jpg)

Слід зазначити, що трикутний парадокс не є теоремою, публікації, які представляють трикутний парадокс, також не містять математичного доведення. Він дійсно наводить евристичний математичний аргумент: якщо децентралізований дружелюбний вузол (, наприклад, споживчий ноутбук ) може перевіряти 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 кожні 12 секунд буде 3 блоби приблизно по 125 кБ, або доступна пропускна здатність даних приблизно 375 кБ для кожного слоту. Припустимо, що дані транзакцій публікуються безпосередньо в ланцюзі, то перекази ERC20 становитимуть приблизно 180 байт, отже, максимальна TPS Rollup на Ethereum становитиме: 375000 / 12 / 180 = 173.6 TPS.

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

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

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

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

! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск] (lab.com/yijian/2024/10/17/images/5be9d7b18dd5154d181bd4c34ad8a3c4.jpg)

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

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

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

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

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

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

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

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

Я вважаю, що довгостроковий реальний шлях це:

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

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

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

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

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

На мою думку, найкраще пояснення – це це зображення дворічної давності:

![Vitalik нова стаття: можливе майбутнє Ethereum, The Surge])