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

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

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

Цього року дорожня карта, зосереджена на Rollup, досягла важливих результатів: з впровадженням blobs 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

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

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

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

Трикутний парадокс не є теоремою, він надає евристичний математичний аргумент: якщо дружній до децентралізації вузол може перевіряти 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 кожні 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, що забезпечить 463-926 TPS для calldata.

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

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

PeerDAS є відносно простим впровадженням "1D sampling". В Ethereum кожен blob є 4096-м многочленом на полях простих чисел (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, тому це рішення в основному є дружнім до розподіленого будівництва блоків. Вузли, які фактично будують блоки, повинні лише мати 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-5d1a322bd6b6dfef0dbb78017226633d.webp###

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

Заміна адреси на вказівники: Якщо раніше використовувався певний адрес, ми можемо замінити 20-байтову адресу на 4-байтовий вказівник, що вказує на певне місце в історії.

Користувацька серіалізація значення угоди------Більшість значень угоди мають невелику кількість знаків, наприклад, 0,25 ETH представляється як 250 000 000 000 000 000 wei. Максимальна базова комісія та пріоритетна комісія також подібні. Тому ми можемо використовувати користувацький десятковий формат з плаваючою комою, щоб представити більшість валютних значень.

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

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

1. Перехід на підпис BLS потребує значних зусиль і знижує можливість посилення безпеки.