Стратегії масштабування Ethereum спочатку мали два напрямки: шардінг та Layer2. Шардінг дозволяє кожному вузлу перевіряти та зберігати лише невелику частину транзакцій, тоді як Layer2 переміщує більшість даних та обчислень поза основну лінію. Ці два шляхи врешті-решт злилися, утворивши дорожню карту, що зосереджена на Rollup, яка досі залишається стратегією масштабування Ethereum.
Дорожня карта, що зосереджується на Rollup, пропонує простий поділ праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим рівнем, тоді як L2 виконує завдання допомоги еко-системі в розширенні. Ця модель є досить поширеною в суспільстві: судова система (L1) існує для захисту контрактів і прав власності, тоді як підприємці (L2) будують на цій основі, сприяючи розвитку людства.
Цього року важливі результати були досягнуті в дорожній карті, зосередженій на Rollup: впровадження блобів EIP-4844 значно збільшило пропускну спроможність даних Ethereum L1, кілька EVM Rollup вже перейшли до першої стадії. Кожен L2 існує як "шар" з внутрішніми правилами та логікою, а різноманітність способів реалізації шарів тепер стала реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наша теперішня задача полягає в тому, щоб завершити цю дорожню карту та вирішити ці проблеми, зберігаючи при цьому стійкість та децентралізацію Ethereum L1.
У майбутньому Ethereum з L2 зможе досягти понад 100000 TPS
Зберігайте децентралізацію та надійність L1
Принаймні деякі L2 повністю успадковують основні властивості Ethereum ( довіри, відкритості, стійкості до цензури )
Ethereum повинен відчуватися як єдина екосистема, а не 34 різні блокчейни
Зміст цього розділу
Трикутник парадоксів масштабованості
Подальший прогрес у вибірці доступності даних
Стиснення даних
Узагальнений Плазма
Доросла система доказів L2
Поліпшення міжопераційності між L2
Розширення виконання на L1
Трикутний парадокс масштабованості
Трикутник суперечностей масштабованості стверджує, що між трьома характеристиками блокчейну: децентралізацією, масштабованістю та безпекою існує суперечність. Це не теорема, а скоріше евристичний аргумент: якщо децентралізований вузол може перевіряти N транзакцій на секунду, а у вас є ланцюг, що обробляє k*N транзакцій на секунду, тоді або кожна транзакція може бути видно лише 1/k вузлами, або ваші вузли стануть потужними, і ланцюг не буде децентралізованим.
Деякі високопродуктивні ланцюги стверджують, що вирішили трилему трійки, зазвичай оптимізуючи програмне забезпечення вузлів. Але це часто є оманливим, оскільки запускати вузли на цих ланцюгах складніше, ніж на Ethereum. Лише з інженерії програмного забезпечення клієнтів L1 неможливо масштабувати Ethereum.
Однак, поєднання семплірування доступності даних із SNARKs дійсно вирішує трикутний парадокс: це дозволяє клієнтам перевіряти доступність великої кількості даних та правильність виконання обчислювальних кроків, завантажуючи лише невелику кількість даних і виконуючи дуже мало обчислень. SNARKs є бездовірчими. Семплірування доступності даних має тонку модель довіри few-of-N, але зберігає основні характеристики немасштабованого ланцюга.
Архітектура Plasma є ще одним рішенням, яке перекладає відповідальність за доступність даних на користувачів. З поширенням SNARKs Plasma стає здійсненним для більш широких сценаріїв.
Після оновлення Dencun 13 березня 2024 року, в Ethereum на кожен слот кожні 12 секунд буде 3 блоби приблизно по 125 кБ, а доступна пропускна спроможність буде приблизно 375 кБ/слот. Припустимо, що дані транзакцій безпосередньо публікуються в мережі, то переказ ERC20 займає близько 180 байтів, максимальна TPS для Rollup в Ethereum складе 173,6.
Додавши calldata, можна досягти 607 TPS. Використовуючи PeerDAS, кількість blob може зрости до 8-16, забезпечуючи 463-926 TPS для calldata.
Це значне покращення для L1, але недостатньо. Наша середньострокова мета – 16 МБ на слот, у поєднанні з компресією даних Rollup, це принесе близько ~58000 TPS.
Що це? Як це працює?
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, кожному вузлу потрібно 1MB пропускної здатності даних на слот. Це ледь можливо, але клієнти з обмеженою пропускною здатністю не можуть здійснювати вибірку. Ми можемо оптимізувати, зменшивши кількість blob і збільшивши їх розмір, але це призведе до підвищення витрат на відновлення.
Отже, в кінцевому підсумку ми хочемо 2D-інтерполяцію, проводячи випадкове вибірку не лише всередині blob, а й між blob. Використовуючи лінійні властивості KZG-комітментів, ми розширюємо набір blob у блоці за допомогою нових віртуальних blob, які надмірно кодують однакову інформацію.
2D вибірка дружня до побудови розподілених блоків. Для фактичної побудови блоків вузлам потрібно лише blob KZG зобов'язання, і вони можуть покладатися на DAS для перевірки доступності. 1D DAS суттєво також дружня до побудови розподілених блоків.
Ознайомлення з оригінальним постом про доступність даних (2018)
Допоміжний документ
Стаття про пояснення DAS
Двовимірна доступність з KZG зобов'язаннями
PeerDAS та статті на ethresear.ch
ЄІП-7594
SubnetDAS на ethresear.ch
Тонкі відмінності у відновлюваності під час 2D вибірки
Що ще потрібно зробити? Які є компроміси?
Далі йдеться про завершення впровадження та запуску PeerDAS. Після цього слід постійно збільшувати кількість blob на PeerDAS, одночасно уважно спостерігаючи за мережею та покращуючи програмне забезпечення для забезпечення безпеки. Ми сподіваємося на більше академічних робіт, які б нормували PeerDAS та його взаємодію з безпекою правил вибору розгалуження.
У майбутньому потрібно визначити ідеальну версію 2D DAS та довести її безпечні властивості. Ми сподіваємося, що в кінцевому підсумку зможемо перейти від KZG до альтернативи, яка є квантово безпечною та не вимагає довіреної настройки. Наразі неясно, які кандидатури є дружніми до розподіленого блокового будівництва.
Я вважаю, що довгостроковий реальний шлях це:
Реалізація ідеальної 2D DAS
Продовжуйте використовувати 1D DAS, жертвуючи ефективністю смуги пропускання для простоти та надійності, приймаючи нижчий верхній рівень даних.
Відмовитися від DA, повністю прийняти Plasma як основну архітектуру Layer2
Навіть якщо ми вирішимо безпосередньо розширити виконання на рівні L1, цей вибір також існує. Тому що, якщо L1 має обробляти велику кількість TPS, блоки L1 стануть дуже великими, клієнтам знадобляться ефективні методи верифікації, тому ми будемо змушені використовувати ті ж технології на рівні L1, що й для Rollup.
Як взаємодіяти з іншими частинами дорожньої карти?
Якщо буде реалізовано стиснення даних, потреба в 2D DAS зменшиться або затримається, якщо Plasma буде широко використано, то потреба ще більше зменшиться. DAS також ставить виклики перед протоколами та механізмами будівництва розподілених блоків: хоча DAS теоретично дружній до розподіленого відновлення, на практиці потрібно поєднати його з пропозицією списку включення пакетів та механізмом вибору гілок навколо нього.
Кожна транзакція в Rollup займає велику кількість місця на ланцюзі: передача ERC20 потребує близько 180 байтів. Навіть за умови ідеальної вибірки даних це обмежує масштабованість Layer протоколів. Кожен слот 16 МБ, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Що буде, якщо ми зможемо зробити так, щоб транзакції в Rollup займали менше байтів в ланцюзі?
Що це таке, як це працює?
Найкраще пояснення – це це зображення двохрічної давності:
У процесі стиснення нульових байтів ми замінюємо кожну довгу послідовність нульових байтів на два байти, які вказують, скільки нульових байтів було. Далі ми використовуємо специфічні властивості транзакцій:
Агрегація підписів: перехід від ECDSA до підписів BLS, де кілька підписів можуть бути об'єднані в один єдиний підпис, що підтверджує дійсність усіх оригінальних підписів. У L1 через високу вартість обчислення для перевірки не розглядається використання BLS, але в L2 в умовах нестачі даних використання BLS має сенс. Агрегативна функція ERC-4337 забезпечує шлях для реалізації цієї функції.
Замініть адресу на покажчики: якщо раніше використовувалася певна адреса, ми можемо замінити 20-байтову адресу на 4-байтовий покажчик, що вказує на певне місце в історії.
Користувацька серіалізація торгових значень: більшість торгових значень мають невелику кількість цифр, наприклад, 0,25 ETH представляється як 250000000000000000 wei. Максимальна базова комісія та пріоритетна комісія також подібні. Тому ми можемо використовувати користувацький формат десяткових дробів для представлення більшості валютних значень.
які є зв'язки з існуючими дослідженнями?
Досліджуйте sequence.xyz
Оптимізація контракту L2 Calldata
Різниця у статусі випуску Rollups на основі доказу ефективності, а не транзакцій
BLS гаманець - реалізація агрегації BLS через ERC-4337
що ще потрібно зробити, які є компроміси?
Далі основна увага буде приділена фактичній реалізації вищезазначеного плану. Основні ваги включають:
Перехід на підписи BLS вимагатиме великих зусиль і знизить сумісність з надійними апаратними чіпами. Можна використовувати упаковку ZK-SNARK з іншими схемами підпису як альтернативу.
Динамічне стиснення (, якщо замінити адреси ) на покажчики, ускладнить код клієнта.
Публікація різниці станів на ланцюгу, а не в транзакціях, знижує аудиторність, що робить багато програм (, таких як блокчейн-браузери ), неможливими для роботи.
Як взаємодіяти з іншими частинами дорожньої карти?
Використання ERC-4337 і в кінцевому підсумку його часткового включення в L2 EVM може значно прискорити впровадження агрегуючих технологій. Розміщення частини ERC-4337 на L1 може прискорити його впровадження на L2.
Узагальнений Плазма
Яку проблему ми вирішуємо?
Навіть використання 16MB блобів та стиснення даних, 58,000 TPS може не повністю задовольнити потреби споживачів у високих пропускних можливостях, таких як платежі та децентралізовані соціальні мережі, особливо враховуючи, що фактори конфіденційності можуть знизити масштабованість у 3-8 разів. Наразі вибір для сценаріїв з високим обсягом угод і низькою вартістю - це Validium, що зберігає дані поза ланцюгом, використовуючи безпечну модель: оператори не можуть вкрасти користувацькі кошти, але можуть тимчасово або назавжди заморозити всі кошти користувачів. Але ми можемо зробити краще.
Що це таке, як це працює?
Plasma є рішенням для масштабування, оператори публікують блоки поза ланцюгом, лише корені Merkle цих блоків розміщуються в ланцюзі. Для кожного блоку оператори надсилають кожному користувачеві Merkle-ветки, що підтверджує зміни або сталість активів цього користувача. Користувачі можуть витягувати активи, надавши Merkle-ветку. Важливо, що ця ветка не обов'язково повинна мати корінь у останньому стані. Тому навіть якщо виникають проблеми з доступністю даних, користувачі все ще можуть відновити активи, витягнувши доступний останній стан. Якщо користувач подає недійсну ветку, через механізм виклику на ланцюзі можна визначити право власності на активи.
Ранні версії Plasma могли обробляти лише платіжні випадки, але не могли ефективно розширити використання. Але
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Ethereum The Surge: Ціль та виклики розширення до 100,000 TPS через L2
Ethereum ймовірне майбутнє: The Surge
Стратегії масштабування Ethereum спочатку мали два напрямки: шардінг та Layer2. Шардінг дозволяє кожному вузлу перевіряти та зберігати лише невелику частину транзакцій, тоді як Layer2 переміщує більшість даних та обчислень поза основну лінію. Ці два шляхи врешті-решт злилися, утворивши дорожню карту, що зосереджена на Rollup, яка досі залишається стратегією масштабування Ethereum.
Дорожня карта, що зосереджується на Rollup, пропонує простий поділ праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим рівнем, тоді як L2 виконує завдання допомоги еко-системі в розширенні. Ця модель є досить поширеною в суспільстві: судова система (L1) існує для захисту контрактів і прав власності, тоді як підприємці (L2) будують на цій основі, сприяючи розвитку людства.
Цього року важливі результати були досягнуті в дорожній карті, зосередженій на Rollup: впровадження блобів EIP-4844 значно збільшило пропускну спроможність даних Ethereum L1, кілька EVM Rollup вже перейшли до першої стадії. Кожен L2 існує як "шар" з внутрішніми правилами та логікою, а різноманітність способів реалізації шарів тепер стала реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наша теперішня задача полягає в тому, щоб завершити цю дорожню карту та вирішити ці проблеми, зберігаючи при цьому стійкість та децентралізацію Ethereum L1.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
The Surge: ключова мета
Зміст цього розділу
Трикутний парадокс масштабованості
Трикутник суперечностей масштабованості стверджує, що між трьома характеристиками блокчейну: децентралізацією, масштабованістю та безпекою існує суперечність. Це не теорема, а скоріше евристичний аргумент: якщо децентралізований вузол може перевіряти N транзакцій на секунду, а у вас є ланцюг, що обробляє k*N транзакцій на секунду, тоді або кожна транзакція може бути видно лише 1/k вузлами, або ваші вузли стануть потужними, і ланцюг не буде децентралізованим.
Деякі високопродуктивні ланцюги стверджують, що вирішили трилему трійки, зазвичай оптимізуючи програмне забезпечення вузлів. Але це часто є оманливим, оскільки запускати вузли на цих ланцюгах складніше, ніж на Ethereum. Лише з інженерії програмного забезпечення клієнтів L1 неможливо масштабувати Ethereum.
Однак, поєднання семплірування доступності даних із SNARKs дійсно вирішує трикутний парадокс: це дозволяє клієнтам перевіряти доступність великої кількості даних та правильність виконання обчислювальних кроків, завантажуючи лише невелику кількість даних і виконуючи дуже мало обчислень. SNARKs є бездовірчими. Семплірування доступності даних має тонку модель довіри few-of-N, але зберігає основні характеристики немасштабованого ланцюга.
Архітектура Plasma є ще одним рішенням, яке перекладає відповідальність за доступність даних на користувачів. З поширенням SNARKs Plasma стає здійсненним для більш широких сценаріїв.
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Подальший прогрес у вибірці доступності даних
Яку проблему ми вирішуємо?
Після оновлення Dencun 13 березня 2024 року, в Ethereum на кожен слот кожні 12 секунд буде 3 блоби приблизно по 125 кБ, а доступна пропускна спроможність буде приблизно 375 кБ/слот. Припустимо, що дані транзакцій безпосередньо публікуються в мережі, то переказ ERC20 займає близько 180 байтів, максимальна TPS для Rollup в Ethereum складе 173,6.
Додавши calldata, можна досягти 607 TPS. Використовуючи PeerDAS, кількість blob може зрости до 8-16, забезпечуючи 463-926 TPS для calldata.
Це значне покращення для L1, але недостатньо. Наша середньострокова мета – 16 МБ на слот, у поєднанні з компресією даних Rollup, це принесе близько ~58000 TPS.
Що це? Як це працює?
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, кожному вузлу потрібно 1MB пропускної здатності даних на слот. Це ледь можливо, але клієнти з обмеженою пропускною здатністю не можуть здійснювати вибірку. Ми можемо оптимізувати, зменшивши кількість blob і збільшивши їх розмір, але це призведе до підвищення витрат на відновлення.
Отже, в кінцевому підсумку ми хочемо 2D-інтерполяцію, проводячи випадкове вибірку не лише всередині blob, а й між blob. Використовуючи лінійні властивості KZG-комітментів, ми розширюємо набір blob у блоці за допомогою нових віртуальних blob, які надмірно кодують однакову інформацію.
2D вибірка дружня до побудови розподілених блоків. Для фактичної побудови блоків вузлам потрібно лише blob KZG зобов'язання, і вони можуть покладатися на DAS для перевірки доступності. 1D DAS суттєво також дружня до побудови розподілених блоків.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
які є посилання на існуючі дослідження?
Що ще потрібно зробити? Які є компроміси?
Далі йдеться про завершення впровадження та запуску PeerDAS. Після цього слід постійно збільшувати кількість blob на PeerDAS, одночасно уважно спостерігаючи за мережею та покращуючи програмне забезпечення для забезпечення безпеки. Ми сподіваємося на більше академічних робіт, які б нормували PeerDAS та його взаємодію з безпекою правил вибору розгалуження.
У майбутньому потрібно визначити ідеальну версію 2D DAS та довести її безпечні властивості. Ми сподіваємося, що в кінцевому підсумку зможемо перейти від KZG до альтернативи, яка є квантово безпечною та не вимагає довіреної настройки. Наразі неясно, які кандидатури є дружніми до розподіленого блокового будівництва.
Я вважаю, що довгостроковий реальний шлях це:
Навіть якщо ми вирішимо безпосередньо розширити виконання на рівні L1, цей вибір також існує. Тому що, якщо L1 має обробляти велику кількість TPS, блоки L1 стануть дуже великими, клієнтам знадобляться ефективні методи верифікації, тому ми будемо змушені використовувати ті ж технології на рівні L1, що й для Rollup.
Як взаємодіяти з іншими частинами дорожньої карти?
Якщо буде реалізовано стиснення даних, потреба в 2D DAS зменшиться або затримається, якщо Plasma буде широко використано, то потреба ще більше зменшиться. DAS також ставить виклики перед протоколами та механізмами будівництва розподілених блоків: хоча DAS теоретично дружній до розподіленого відновлення, на практиці потрібно поєднати його з пропозицією списку включення пакетів та механізмом вибору гілок навколо нього.
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Стиснення даних
Яку проблему ми вирішуємо?
Кожна транзакція в Rollup займає велику кількість місця на ланцюзі: передача ERC20 потребує близько 180 байтів. Навіть за умови ідеальної вибірки даних це обмежує масштабованість Layer протоколів. Кожен слот 16 МБ, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Що буде, якщо ми зможемо зробити так, щоб транзакції в Rollup займали менше байтів в ланцюзі?
Що це таке, як це працює?
Найкраще пояснення – це це зображення двохрічної давності:
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
У процесі стиснення нульових байтів ми замінюємо кожну довгу послідовність нульових байтів на два байти, які вказують, скільки нульових байтів було. Далі ми використовуємо специфічні властивості транзакцій:
Агрегація підписів: перехід від ECDSA до підписів BLS, де кілька підписів можуть бути об'єднані в один єдиний підпис, що підтверджує дійсність усіх оригінальних підписів. У L1 через високу вартість обчислення для перевірки не розглядається використання BLS, але в L2 в умовах нестачі даних використання BLS має сенс. Агрегативна функція ERC-4337 забезпечує шлях для реалізації цієї функції.
Замініть адресу на покажчики: якщо раніше використовувалася певна адреса, ми можемо замінити 20-байтову адресу на 4-байтовий покажчик, що вказує на певне місце в історії.
Користувацька серіалізація торгових значень: більшість торгових значень мають невелику кількість цифр, наприклад, 0,25 ETH представляється як 250000000000000000 wei. Максимальна базова комісія та пріоритетна комісія також подібні. Тому ми можемо використовувати користувацький формат десяткових дробів для представлення більшості валютних значень.
які є зв'язки з існуючими дослідженнями?
що ще потрібно зробити, які є компроміси?
Далі основна увага буде приділена фактичній реалізації вищезазначеного плану. Основні ваги включають:
Перехід на підписи BLS вимагатиме великих зусиль і знизить сумісність з надійними апаратними чіпами. Можна використовувати упаковку ZK-SNARK з іншими схемами підпису як альтернативу.
Динамічне стиснення (, якщо замінити адреси ) на покажчики, ускладнить код клієнта.
Публікація різниці станів на ланцюгу, а не в транзакціях, знижує аудиторність, що робить багато програм (, таких як блокчейн-браузери ), неможливими для роботи.
Як взаємодіяти з іншими частинами дорожньої карти?
Використання ERC-4337 і в кінцевому підсумку його часткового включення в L2 EVM може значно прискорити впровадження агрегуючих технологій. Розміщення частини ERC-4337 на L1 може прискорити його впровадження на L2.
Узагальнений Плазма
Яку проблему ми вирішуємо?
Навіть використання 16MB блобів та стиснення даних, 58,000 TPS може не повністю задовольнити потреби споживачів у високих пропускних можливостях, таких як платежі та децентралізовані соціальні мережі, особливо враховуючи, що фактори конфіденційності можуть знизити масштабованість у 3-8 разів. Наразі вибір для сценаріїв з високим обсягом угод і низькою вартістю - це Validium, що зберігає дані поза ланцюгом, використовуючи безпечну модель: оператори не можуть вкрасти користувацькі кошти, але можуть тимчасово або назавжди заморозити всі кошти користувачів. Але ми можемо зробити краще.
Що це таке, як це працює?
Plasma є рішенням для масштабування, оператори публікують блоки поза ланцюгом, лише корені Merkle цих блоків розміщуються в ланцюзі. Для кожного блоку оператори надсилають кожному користувачеві Merkle-ветки, що підтверджує зміни або сталість активів цього користувача. Користувачі можуть витягувати активи, надавши Merkle-ветку. Важливо, що ця ветка не обов'язково повинна мати корінь у останньому стані. Тому навіть якщо виникають проблеми з доступністю даних, користувачі все ще можуть відновити активи, витягнувши доступний останній стан. Якщо користувач подає недійсну ветку, через механізм виклику на ланцюзі можна визначити право власності на активи.
Ранні версії Plasma могли обробляти лише платіжні випадки, але не могли ефективно розширити використання. Але