Майбутнє Ethereum: сплеск

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

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

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

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

Іншим способом вирішення трьох труднощів є архітектура 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, то це буде 607 TPS. Використовуючи PeerDAS, кількість blob може зрости до 8-16, що забезпечить 463-926 TPS для calldata.

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

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

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

PeerDAS є відносно простим впровадженням "1D sampling". В Ethereum кожен blob є поліномом ступеня 4096 у полі простих чисел з 253 елементами. Ми транслюємо частини полінома, де кожна частина містить 16 оцінок з 16 сусідніх координат, вибраних з загальних 8192 координат. Серед цих 8192 оцінок будь-які 4096 можуть відновити blob.

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

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

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

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

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

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

Далі йдеться про завершення впровадження та запуску PeerDAS. Після цього постійно збільшуйте кількість blob на PeerDAS, одночасно уважно спостерігаючи за мережею та вдосконалюючи програмне забезпечення, щоб забезпечити безпеку - це поступовий процес. Одночасно ми сподіваємось на більше академічної роботи для регулювання PeerDAS та інших версій DAS, а також їх взаємодії з питаннями безпеки, такими як правила вибору розгалуження.

На більш віддалених етапах у майбутньому нам потрібно буде зробити більше роботи, щоб визначити ідеальну версію 2D DAS та підтвердити її безпечні властивості. Ми також сподіваємося врешті-решт перейти від KZG до альтернативи, яка є квантово-безпечною та не потребує надійних налаштувань. Наразі нам не зовсім зрозуміло, які кандидати є дружніми до розподіленого будівництва блоків. Навіть використання дорогих "грубої сили" технологій, навпаки, використання рекурсивного STARK для генерування доказів дійсності для відновлення рядків і стовпців недостатньо для задоволення потреб, оскільки, хоча технічно розмір одного STARK дорівнює O(log(n) * log(log(n)) хеш-значення, на практиці STARK майже такого ж розміру, як і весь blob.

Я вважаю, що довгостроковий реальний шлях є:

1. Реалізація ідеального 2D DAS;
2. Наполягайте на використанні 1D DAS, жертвуючи ефективністю смуги пропускання, щоб прийняти нижчий верхній межу даних заради простоти та надійності.
3. Відмовитися від DA, повністю прийняти Plasma як нашу основну архітектуру Layer2.

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

Як взаємодіяти з іншими частинами дорожньої карти?

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

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

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

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

Наступним кроком є фактичне впровадження наведеної вище схеми. Основні компроміси включають:

1. Перехід на підпис BLS вимагатиме великих зусиль і знизить сумісність із надійними апаратними чіпами, які можуть підвищити безпеку. Можна використовувати упаковку ZK-SNARK з іншими схемами підпису як альтернативу.

2. Динамічне стиснення (, наприклад, заміна адреси ) на вказівники ускладнить код клієнта.

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

Як взаємодіяти з іншими частинами дорожньої карти?

Використання ERC-4337 та остаточне включення його частин до L2 EVM може значно прискорити впровадження агрегуючих технологій. Розміщення частин ERC-4337 на L1 може пришвидшити його впровадження на L2.

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

Узагальнений плазма

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

Навіть з використанням 16 МБ blob та стиснення даних, 58 000 TPS може не бути достатнім для повного задоволення потреб споживчих платежів, децентралізованих соціальних мереж або інших областей з високою пропускною здатністю, особливо коли ми починаємо враховувати фактори конфіденційності, що може знизити масштабованість у 3-8 разів. Для сценаріїв з високим обсягом транзакцій і низькою вартістю одним із поточних варіантів є використання Validium, яке зберігає дані поза ланцюгом і використовує цікавий модель безпеки: оператори не можуть вкрасти кошти користувачів, але вони можуть тимчасово або назавжди заморозити всі кошти користувачів. Але ми можемо зробити краще.

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

Plasma є рішенням для масштабування, яке передбачає, що оператор публікує блоки поза ланцюгом і розміщує корінь Меркла цих блоків на ланцюгу. Для кожного блоку оператор надсилає кожному користувачеві гілку Меркла, щоб підтвердити, які зміни сталися з активами цього користувача, або що їх не було. Користувачі можуть витягувати свої активи, надаючи гілку Меркла. Важливо, що ця гілка не обов'язково повинна мати корінь у найновішому стані. Таким чином, навіть якщо виникають проблеми з доступністю даних, користувачі все ще можуть відновити свої активи, отримавши доступ до свого останнього доступного стану. Якщо користувач подає недійсну гілку, то легітимність активів може бути перевірена за допомогою механізму виклику на ланцюзі.

Ранні версії Plasma могли обробляти лише випадки використання платежів, не здатні ефективно розширюватися далі. Однак, якщо ми вимагатимемо, щоб кожен корінь перевірявся за допомогою SNARK, то Plasma стане значно потужнішою. Кожна гра виклику може бути значно спрощена,