Ethereum можливе майбутнє: The Surge

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

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

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

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

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

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

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

4. Ethereum повинен відчуватися як єдина екосистема, а не 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 стала більш досяжною для значно ширшого спектра використання.

! Віталік Новини: Можливе майбутнє Ethereum, сплеск

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

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

13 березня 2024 року, коли оновлення Dencun буде запущено, блокчейн Ethereum матиме 3 блоби приблизно по 125 кБ на слот кожні 12 секунд, або доступну ширину смуги даних приблизно 375 кБ на слот. Припустимо, що дані транзакцій публікуються безпосередньо в ланцюзі, то ERC20 переказ займає близько 180 байт, отже, максимальна TPS Rollup на Ethereum становитиме: 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 sampling". В Ethereum кожен blob є 4096-м поліномом на просторовому полі 253-бітного простого числа (. Ми транслюємо частини полінома, де кожна частина містить 16 оцінок з сусідніх 16 координат з загальних 8192 координат. З цих 8192 оцінок будь-які 4096 ) можуть бути відновлені відповідно до поточно запропонованих параметрів: будь-які 64 з 128 можливих зразків ( можуть відновити blob.

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

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

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

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

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

! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(

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

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

! Віталік Новини: Можливе майбутнє Ethereum, сплеск

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

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

Замініть адреси на вказівники: якщо Етер