Аналіз технологічного оновлення Ethereum The Surge

З початку жовтня цього року співзасновник Ethereum опублікував серію статей про можливості майбутнього протоколу Ethereum, що охоплюють шість частин дорожньої карти розвитку Ethereum. У цій статті буде проаналізовано другу частину цієї серії The Surge, зосереджуючи увагу на масштабованості Ethereum та його довгостроковому розвитку. З технологічної дорожньої карти цього етапу ми можемо детально зрозуміти, як Ethereum перетвориться на протокол, здатний обробляти величезний попит (TPS досягне 100,000+), при цьому зберігаючи децентралізацію та безпеку.

Вітчизна Ethereum

По суті, Ethereum призначений для того, щоб стати основою децентралізованого Інтернету. Етер підтримує складні децентралізовані програми завдяки автоматично виконуваному коду смарт-контрактів, і ця гнучкість робить його переважним блокчейном для розробників, які створюють децентралізовані програми, включаючи DeFi, NFT тощо.

Однак, Ethereum має обмеження у сфері масштабованості. Ethereum L1 може обробляти лише близько 15-30 транзакцій на секунду, що є значною відстанню від традиційних платіжних мереж. Це призводить до високих комісій за газ під час заторів у мережі та обмежує можливості Ethereum стати глобальною інфраструктурою. Саме це питання має вирішити The Surge.

Основні цілі The Surge такі:

• Ethereum L1+L2 досягає 100,000+ TPS;
• Зберегти децентралізацію та стабільність L1;
• Принаймні деякі L2 повністю успадковують основні властивості Ethereum (без довіри, відкритість, стійкість до цензури);
• Максимізація міжоперабельності між L2: Ethereum має бути екосистемою, а не десятками різних блокчейнів.

Майбутнє, зосереджене на rollup

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

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

Дорожня карта зосереджена на rollup вважається довгостроковим рішенням для масштабування. Ethereum 2.0 знизив енергоспоживання шляхом переходу з PoW на PoS через The Merge, а rollup, як довгострокове рішення для масштабування, вважається наступним важливим етапом.

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

Зразок доступності даних (DAS) подальший розвиток

Іншим ключовим аспектом Surge є вибірка доступності даних (DAS), технологія, що має на меті вирішення проблеми доступності даних. У децентралізованих мережах, таких як Ethereum, усі вузли можуть перевіряти дані, не зберігаючи або не завантажуючи весь обсяг інформації, що є надзвичайно важливим.

DAS дозволяє вузлам перевіряти дані без доступу до повного набору даних, що підвищує масштабованість і ефективність.

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

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

На більш віддалених етапах у майбутньому потрібно буде виконати більше роботи для визначення ідеальної версії 2D DAS та підтвердження його безпекових властивостей.

Довгостроковий реальний шлях це:

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

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

Plasma та інші рішення

Окрім Rollup, одним з ранніх запропонованих рішень для масштабування поза ланцюгом є Plasma, яке також є ще одним L2 рішенням.

Plasma створює дочірні ланцюги, які обробляють транзакції незалежно від основного ланцюга Ethereum і регулярно подають резюме до основної мережі. Для кожного блоку оператор надсилає кожному користувачеві Merkle-діагональ, щоб підтвердити зміни стану активів цього користувача. Користувачі можуть вилучати свої активи, надаючи Merkle-діагональ. Важливо, що ця діагональ не обов'язково повинна бути коренем з останнього стану.

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

Хоча розробка Plasma в певній мірі відстає від rollup, вона все ще вважається частиною більш широкого набору інструментів для масштабування Ethereum.

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

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

Один із способів створення EVM plasma-ланцюга (але не єдиний спосіб) полягає в наступному: використовувати ZK-SNARK для побудови паралельного UTXO-дерева, яке відображає зміни балансу, здійснені EVM, визначаючи унікальну відповідність "однієї монети" в різні історичні періоди. На його основі можна побудувати структуру Plasma.

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

Поліпшення міжоперабельності між L2

Сьогодні одним із основних викликів L2 екосистеми є слабка міжоперабельність між L2, і як зробити так, щоб використання L2 екосистеми відчувалося так, ніби ви користуєтеся єдиною екосистемою Ethereum, є нагальною проблемою для покращення.

Покращення міжоперабельності між L2 має багато категорій. Теоретично, Ethereum, зосереджений на Rollup, подібний до виконуваного шардінгу L1. Наразі екосистема Ethereum L2 на практиці має такі проблеми, які віддалені від ідеального стану:

• Адреса конкретного ланцюга: адреса повинна містити інформацію про ланцюг (L1, Optimism, Arbitrum......). Як тільки це буде реалізовано, можна буде здійснити процес передачі через L2, просто вставивши адресу в поле відправлення, при цьому гаманець може в фоновому режимі самостійно обробити, як надсилати (включаючи використання крос-ланцюгового протоколу).

• Платіжний запит для конкретного ланцюга: повинна бути можливість легко та стандартизовано створювати повідомлення у формі "надішліть мені X токенів типу Y на ланцюзі Z". Це має два основних сценарії застосування: платежі між людьми або платежі між людьми та торговими послугами; запит фінансування dApp.

• Кросчейн обмін та плата за газ: має бути стандартизований відкритий протокол для вираження кросчейн операцій. ERC-7683 та RIP-7755 роблять спроби в цій сфері, хоча обидва ці протоколи мають більш широкий діапазон застосування, ніж ці конкретні випадки.

• Легкий клієнт: користувачі повинні мати можливість фактично перевіряти ланцюг, з яким вони взаємодіють, а не просто покладатися на постачальника RPC. ERC-3668 (CCIP-read) є одним із стратегій для досягнення цієї мети.

• Концепція спільного токен-мосту: уявімо світ, де всі L2 є ролапами з доказами валідності, і кожен слот подає на Ethereum, для того щоб у рідному стані перемістити актив з одного L2 на інший, все ще потрібно вивести та внести кошти, що потребує сплати великої кількості L1 Gas.

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

• Синхронна комбінованість: дозволяє здійснювати синхронні виклики між певними L2 і L1 або між кількома L2. Це допомагає підвищити фінансову ефективність DeFi протоколів. Перше можна реалізувати без жодної координації між L2; друге ж вимагає спільного сортування. Технології на базі rollup автоматично підходять для всіх цих технологій.

Багато прикладів вище стикаються з проблемою, коли стандартизувати та які шари стандартизувати. Якщо стандартизація відбудеться занадто рано, це може закріпити погане рішення. Якщо стандартизація відбудеться занадто пізно, це може призвести до непотрібної фрагментації.

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

Продовження розширення Ethereum L1

Розширення Ethereum L1 та забезпечення його здатності продовжувати вміщати все більше випадків використання є дуже цінним.

Існує три стратегії розширення L1, які можуть бути реалізовані окремо або паралельно:

1. Покращити технології (наприклад, клієнтський код, безстатевий клієнт, історичні терміни) для полегшення валідації L1, а потім підвищити обмеження Gas;
2. Зменшити витрати на певні операції, не збільшуючи ризик найгіршого сценарію, та збільшити середню ємність;
3. Нативні Rollups (тобто, створення N паралельних копій EVM).

Ці різні технології мають свої власні компроміси. Наприклад, нативні rollups мають таку ж слабкість у комбінованості, як і звичайні rollups: неможливо надіслати єдину транзакцію для синхронного виконання операцій через кілька rollup. Підвищення ліміту Gas послабить інші переваги, які можна досягти за рахунок спрощення верифікації L1, такі як збільшення частки користувачів, що запускають верифікаційні вузли, а також збільшення кількості соло-стейкерів. В залежності від способу реалізації, зменшення вартості певних операцій в EVM може підвищити загальну складність EVM.

Децентралізація та безпека

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