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

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

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

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

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

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

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

2. Підтримувати децентралізацію та надійність L1;

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

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

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

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

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

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

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

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

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

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

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

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

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

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, що надасть 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.

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

Принцип роботи 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, ці віртуальні blob надмірно кодують ту ж інформацію.

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

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

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

Агрегація підписів: ми перейшли від підписів ECDSA до підписів BLS