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

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

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

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

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

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

1. У майбутньому Ethereum може досягти понад 100 000 TPS через L2;
2. Підтримувати децентралізацію та надійність L1;
3. Щонайменше деякі L2 повністю успадкували основні властивості Ethereum (, такі як довіра, відкритість, стійкість до цензури );
4. Ethereum має відчуватися як єдина екосистема, а не 34 різні блокчейни.

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

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

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

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

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

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

Наразі в Ethereum кожні 12 секунд слот має 3 приблизно 125 кБ блоба, а доступна пропускна здатність даних становить приблизно 375 кБ. Припустимо, що дані транзакцій публікуються безпосередньо в мережі, ERC20 перекази становлять приблизно 180 байт, тому максимальний TPS для Rollup в Ethereum становить 173,6. Нашою середньостроковою метою є досягнення 16 МБ на кожен слот, якщо поєднати поліпшення стиснення даних Rollup, це принесе близько 58000 TPS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16000000 / 12 / 180 = 7407 TPS

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

Існує кілька методів стиснення даних:

• Нульовий байт стиснення: замінює кожну довгу послідовність нульових байтів на два байти, що вказують, скільки нульових байтів.

• Агегація підписів: перехід від ECDSA підпису до BLS підпису, особливістю BLS підпису є те, що кілька підписів можуть бути об'єднані в один єдиний підпис, який може підтвердити дійсність всіх оригінальних підписів.

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

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

• Різниця у стані випуску Rollups на основі доказів ефективності, а не транзакцій.

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

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

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

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

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

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

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

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

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

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

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

Ключове розуміння полягає в тому, що система Plasma не потребує досконалості. Навіть якщо ви можете захистити лише підгрупу активів (, наприклад, лише токени, які не переміщались за останній тиждень ), ви вже значно покращили поточний стан надмірно масштабованого EVM (, а саме Validium ).

Інший тип структури - це гібридний Plasma/Rollup, наприклад Intmax. Ці конструкції поміщають дуже невелику кількість даних кожного користувача на ланцюг (, наприклад, 5 байт ). Це дозволяє отримати деякі характеристики, що знаходяться між Plasma і Rollup: у випадку з Intmax ви можете отримати дуже високу масштабованість і конфіденційність, хоча навіть при обсязі 16 МБ теоретично обмежено приблизно 16.