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

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

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

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

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

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

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

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

Протягом багатьох років деякі високопродуктивні ланцюги стверджували, що вирішили трилему без зміни архітектури, зазвичай завдяки використанню технік програмної інженерії для оптимізації вузлів. Це завжди є оманливим, оскільки запуск вузлів на цих ланцюгах значно складніший, ніж на 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 мільйонів 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 біт. Ми транслюємо частки полінома, де кожна частка містить 16 оцінок з сусідніх 16 координат з загальних 8192 координат. З цих 8192 оцінок будь-які 4096 ( відповідно до поточних запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.

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

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

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

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

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

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

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

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

використовувати po