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

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

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

Вибух: ключова мета

1. В майбутньому Ethereum через L2 може досягти понад 100 000 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, сплеск

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

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

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

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

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

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

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.

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

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

PeerDAS є відносно простим втіленням "1D sampling". В Ethereum, кожен 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 * по 512 байт на кожен зразок для кожного blob = 1 MB пропускної здатності даних на слот. Це лише ледве в межах нашого допустимого: це можливо, але це означає, що клієнти з обмеженою пропускною здатністю не зможуть підбирати вибірки. Ми можемо оптимізувати це в певній мірі, зменшуючи кількість blob і збільшуючи їхній розмір, але це підвищить витрати на відновлення.

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

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

Вкрай важливо, що розширення обіцянки обчислення не потребує наявності 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, сплеск])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp###

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

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