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

The Surge: Ключові цілі

1. Майбутнє Ethereum через L2 може досягти понад 100000 TPS;

2. Підтримка децентралізації та надійності L1;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13 березня 2024 року, коли оновлення Dencun буде запущено, на кожному слоті кожні 12 секунд буде 3 блоби приблизно по 125 кБ, або приблизна доступна пропускна здатність даних для кожного слоту становитиме близько 375 кБ. Припустимо, що дані транзакцій публікуються безпосередньо в ланцюгу, то переказ ERC20 становить приблизно 180 байт, отже, максимальна TPS на Rollup становитиме: 375000 / 12 / 180 = 173,6 TPS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

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

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