У початковій дорожній карті Ethereum було дві стратегії масштабування: шардінг та протоколи Layer2. Ці дві стратегії врешті-решт об'єдналися, сформувавши дорожню карту, зосереджену на Rollup, яка досі залишається стратегією масштабування Ethereum.
Дорожня карта, зосереджена на Rollup, пропонує простий розподіл обов'язків: Ethereum L1 зосереджується на тому, щоб бути потужним і децентралізованим базовим шаром, тоді як L2 виконує завдання допомоги в розширенні екосистеми. Ця модель присутня в суспільстві всюди: існування судової системи (L1) покликане захищати контракти та майнові права, тоді як підприємці (L2) будують на цій основі, просуваючи людство вперед.
Цього року дорожня карта, зосереджена на Rollup, досягла важливих результатів: з впровадженням EIP-4844 blobs дані смуги пропускання Ethereum L1 значно зросли, кілька EVM Rollup перейшли до першої стадії. Кожен L2 існує як "шар" з власними правилами і логікою, різноманітність і різноманітність реалізації шарів тепер стали реальністю. Проте цей шлях стикається з деякими унікальними викликами. Таким чином, наше завдання зараз полягає у завершенні дорожньої карти, зосередженої на Rollup, вирішенні цих проблем, одночасно зберігаючи стійкість і децентралізацію Ethereum L1.
Трикутник масштабованості стверджує, що між трьома характеристиками блокчейну існує суперечність: децентралізація (, низька вартість експлуатації вузлів ), масштабованість (, велика кількість оброблюваних транзакцій ) та безпека (, оскільки зловмисник повинен знищити значну частину вузлів у мережі, щоб зробити одну транзакцію недійсною ).
Варто зазначити, що трикутний парадокс не є теоремою, а публікації, що представляють трикутний парадокс, також не супроводжуються математичними доказами. Вона надає евристичний математичний аргумент: якщо децентралізований дружній вузол може перевіряти 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 на кожному слоті через 12 секунд буде 3 блоби приблизно по 125 кБ, або доступна пропускна спроможність даних кожного слота буде приблизно 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, що забезпечить для calldata 463-926 TPS.
Це значне покращення для Ethereum L1, але цього недостатньо. Ми хочемо більше масштабованості. Нашою середньостроковою метою є 16 МБ на кожен слот, що в поєднанні з вдосконаленнями стиснення даних Rollup принесе приблизно 58000 TPS.
Що це? Як це працює?
PeerDAS є відносно простим впровадженням "1D sampling". В Ethereum кожен blob є 4096-многочленом у полі простих чисел з 253 елементами. Ми транслюємо частини многочлена, де кожна частина містить 16 оцінок з сусідніх 16 координат з загалом 8192 координат. Серед цих 8192 оцінок будь-які 4096 з ( відповідно до нині запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, де i-та підмережа транслює i-ий зразок будь-якого blob, і запитує у глобальних p2p-мережах однолітків (, хто буде прослуховувати різні підмережі ), щоб запросити необхідні йому blob з інших підмереж. Більш консервативна версія SubnetDAS використовує лише механізм підмереж без додаткових запитів до рівня однолітків. Поточна пропозиція полягає в тому, щоб дозволити учасникам з підтвердженням частки використовувати SubnetDAS, тоді як інші вузли (, тобто клієнти ), використовують PeerDAS.
З теоретичної точки зору, ми можемо масштабувати "1D sampling" до значних розмірів: якщо ми збільшимо максимальну кількість blob до 256( з метою 128), то ми зможемо досягти цілі 16MB, а в зразках доступності даних кожен вузол має 16 зразків * 128 blob * по 512 байтів на кожен зразок кожного blob = 1 MB пропускної здатності даних на кожен слот. Це лише зледве в межах нашого допустимого діапазону: це можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть здійснювати вибірку. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob і збільшуючи розмір blob, але це призведе до підвищення витрат на відновлення.
Отже, в кінцевому підсумку ми хочемо зробити крок далі і провести 2D-відібрання, яке не тільки здійснює випадкову вибірку всередині blob, але й між blob. Використовуючи лінійні властивості KZG-комітментів, ми розширюємо набір blob у блоці за допомогою нового набору віртуальних blob, які надмірно кодують ту ж інформацію.
Критично важливо, що розширення обчислених зобов'язань не потребує наявності blob, тому ця схема в принципі є дружньою до розподіленого будівництва блоків. Фактичні вузли, які будують блоки, повинні лише мати blob KZG зобов'язання, і вони можуть покладатися на вибірку доступності даних для перевірки доступності блоків даних. Одновимірна вибірка доступності даних по суті також є дружньою до розподіленого будівництва блоків.
Далі йдеться про завершення впровадження та запуску PeerDAS. Після цього постійно збільшується кількість blob на PeerDAS, одночасно ретельно спостерігаючи за мережею та вдосконалюючи програмне забезпечення для забезпечення безпеки, це поступовий процес. Водночас ми сподіваємось на більше академічних досліджень для регулювання PeerDAS та інших версій DAS, а також їх взаємодії з такими питаннями, як безпека правил вибору розгалуження.
На подальших етапах ми повинні виконати більше роботи, щоб визначити ідеальну версію 2D DAS і довести її безпечні властивості. Ми також сподіваємося в кінцевому підсумку перейти від KZG до альтернативи, яка є квантово-безпечною та не вимагає надійної настройки. Наразі нам неясно, які кандидатури дружні до розподіленого блокового будівництва. Навіть використання дорогих "грубої сили" технологій, навіть з рекурсивним STARK для генерації доказів дійсності, необхідних для відновлення рядків і стовпців, недостатньо, оскільки, хоча технічно розмір STARK становить O(log(n) * log(log(n)) хешів ( з використанням STIR), насправді STARK майже такого ж розміру, як весь blob.
Я вважаю, що довгостроковий реальний шлях є:
Реалізація ідеального 2D DAS;
Дотримуйтесь використання 1D DAS, жертвуючи ефективністю смуги пропускання вибірки, щоб прийняти нижню межу даних заради простоти та надійності.
Відмовитися від 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 займала менше байтів в ланцюзі?
Що це таке і як це працює?
У нульових байтах стиснення, два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів. Далі ми використали специфічні властивості транзакцій:
Агрегація підписів: ми перейшли від підписів ECDSA до підписів BLS. Особливість підписів BLS полягає в тому, що кілька підписів можуть бути об'єднані в один єдиний підпис, який може підтвердити дійсність усіх оригінальних підписів. На рівні L1, оскільки навіть при агрегації обчислювальні витрати на верифікацію залишаються високими, тому використання підписів BLS не розглядається. Але в середовищі L2, де дані є дефіцитом, використання підписів BLS має сенс. Агрегаційна функція ERC-4337 забезпечує шлях для реалізації цієї можливості.
Замініть адреси на вказівники: якщо раніше використовувалася певна адреса, ми можемо замінити 20-байтову адресу на 4-байтовий вказівник, що вказує на певне місце в історії.
Кастомна серіалізація торгових значень------Більшість торгових значень мають невелику кількість знаків, наприклад, 0.25 Етер відображається як 250
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
22 лайків
Нагородити
22
4
Поділіться
Прокоментувати
0/400
BrokeBeans
· 07-22 21:16
Все ще займаєтеся розширенням даних? Вже всі набридло.
Переглянути оригіналвідповісти на0
BearMarketSurvivor
· 07-22 21:15
Задня лінія постачання стабільна, бойова потужність Ethereum постійно посилюється
Ethereum розширення: Аналіз стратегії масштабування The Surge та майбутні цілі
The Surge: Майбутнє масштабованості Ethereum
У початковій дорожній карті Ethereum було дві стратегії масштабування: шардінг та протоколи Layer2. Ці дві стратегії врешті-решт об'єдналися, сформувавши дорожню карту, зосереджену на Rollup, яка досі залишається стратегією масштабування Ethereum.
Дорожня карта, зосереджена на Rollup, пропонує простий розподіл обов'язків: Ethereum L1 зосереджується на тому, щоб бути потужним і децентралізованим базовим шаром, тоді як L2 виконує завдання допомоги в розширенні екосистеми. Ця модель присутня в суспільстві всюди: існування судової системи (L1) покликане захищати контракти та майнові права, тоді як підприємці (L2) будують на цій основі, просуваючи людство вперед.
Цього року дорожня карта, зосереджена на Rollup, досягла важливих результатів: з впровадженням EIP-4844 blobs дані смуги пропускання Ethereum L1 значно зросли, кілька EVM Rollup перейшли до першої стадії. Кожен L2 існує як "шар" з власними правилами і логікою, різноманітність і різноманітність реалізації шарів тепер стали реальністю. Проте цей шлях стикається з деякими унікальними викликами. Таким чином, наше завдання зараз полягає у завершенні дорожньої карти, зосередженої на Rollup, вирішенні цих проблем, одночасно зберігаючи стійкість і децентралізацію Ethereum L1.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
The Surge:Ключові цілі
Зміст цього розділу
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Парадокс трикутника масштабованості
Трикутник масштабованості стверджує, що між трьома характеристиками блокчейну існує суперечність: децентралізація (, низька вартість експлуатації вузлів ), масштабованість (, велика кількість оброблюваних транзакцій ) та безпека (, оскільки зловмисник повинен знищити значну частину вузлів у мережі, щоб зробити одну транзакцію недійсною ).
Варто зазначити, що трикутний парадокс не є теоремою, а публікації, що представляють трикутний парадокс, також не супроводжуються математичними доказами. Вона надає евристичний математичний аргумент: якщо децентралізований дружній вузол може перевіряти N транзакцій за секунду, і у вас є ланцюг, що обробляє k*N транзакцій за секунду, тоді (i) кожна транзакція може бачити лише 1/k вузлів, що означає, що атакуючому потрібно зламати лише кілька вузлів, щоб через одну зловмисну транзакцію, або (ii) ваші вузли стануть потужними, а ваш ланцюг не буде децентралізованим. Мета цієї статті зовсім не в тому, щоб довести, що порушити трикутний парадокс неможливо; швидше, вона має на меті продемонструвати, що порушення тризначного парадоксу є складним, і це вимагає в певній мірі вийти за межі мисленнєвої рамки, що міститься в цьому аргументі.
Протягом багатьох років деякі високопродуктивні ланцюги часто стверджували, що вони вирішують тривимірну парадоксію, не змінюючи архітектуру в основі, зазвичай шляхом використання програмних інженерних прийомів для оптимізації вузлів. Це завжди є оманливим, адже запускати вузли на цих ланцюгах значно складніше, ніж на Ethereum. У цій статті буде розглянуто, чому це так, і чому лише завдяки програмній інженерії L1 клієнтів не можна масштабувати Ethereum?
Однак, поєднання вибірки доступності даних і SNARKs дійсно вирішує трикутний парадокс: це дозволяє клієнтам перевіряти, що певна кількість даних є доступною, і що певна кількість обчислювальних кроків виконуються правильно, завантажуючи лише невелику кількість даних і виконуючи дуже мало обчислень. SNARKs є без довіри. Вибірка доступності даних має тонку модель довіри few-of-N, але вона зберігає основні характеристики нездатних до масштабування ланцюгів, а саме, що навіть атака на 51% не може примусити мережу прийняти погані блоки.
Іншим способом вирішення трьох важких ситуацій є архітектура Plasma, яка використовує хитрі технології, щоб у спосіб, сумісний з стимулюваннями, покласти відповідальність за наявність даних на користувачів. Ще в 2017-2019 роках, коли у нас був лише засіб шахрайських доказів для розширення обчислювальних можливостей, 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 (: кожен слот 30 мільйонів Gas / за байт 16 gas = кожен слот 1,875,000 байтів ), то це становитиме 607 TPS. Використовуючи PeerDAS, кількість blob може збільшитися до 8-16, що забезпечить для calldata 463-926 TPS.
Це значне покращення для Ethereum L1, але цього недостатньо. Ми хочемо більше масштабованості. Нашою середньостроковою метою є 16 МБ на кожен слот, що в поєднанні з вдосконаленнями стиснення даних Rollup принесе приблизно 58000 TPS.
Що це? Як це працює?
PeerDAS є відносно простим впровадженням "1D sampling". В Ethereum кожен blob є 4096-многочленом у полі простих чисел з 253 елементами. Ми транслюємо частини многочлена, де кожна частина містить 16 оцінок з сусідніх 16 координат з загалом 8192 координат. Серед цих 8192 оцінок будь-які 4096 з ( відповідно до нині запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, де i-та підмережа транслює i-ий зразок будь-якого blob, і запитує у глобальних p2p-мережах однолітків (, хто буде прослуховувати різні підмережі ), щоб запросити необхідні йому blob з інших підмереж. Більш консервативна версія SubnetDAS використовує лише механізм підмереж без додаткових запитів до рівня однолітків. Поточна пропозиція полягає в тому, щоб дозволити учасникам з підтвердженням частки використовувати SubnetDAS, тоді як інші вузли (, тобто клієнти ), використовують PeerDAS.
З теоретичної точки зору, ми можемо масштабувати "1D sampling" до значних розмірів: якщо ми збільшимо максимальну кількість blob до 256( з метою 128), то ми зможемо досягти цілі 16MB, а в зразках доступності даних кожен вузол має 16 зразків * 128 blob * по 512 байтів на кожен зразок кожного blob = 1 MB пропускної здатності даних на кожен слот. Це лише зледве в межах нашого допустимого діапазону: це можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть здійснювати вибірку. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob і збільшуючи розмір blob, але це призведе до підвищення витрат на відновлення.
Отже, в кінцевому підсумку ми хочемо зробити крок далі і провести 2D-відібрання, яке не тільки здійснює випадкову вибірку всередині 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)) хешів ( з використанням STIR), насправді STARK майже такого ж розміру, як весь blob.
Я вважаю, що довгостроковий реальний шлях є:
Будь ласка, зверніть увагу, що навіть якщо ми вирішимо безпосередньо розширити виконання на шарі L1, цей вибір також існує. Це пов'язано з тим, що якщо шар L1 має обробляти велику кількість TPS, блоки L1 стануть дуже великими, і клієнти захочуть мати ефективний спосіб перевірки їхньої правильності, тому нам доведеться використовувати на шарі L1 ті ж технології, що й у Rollup(, такі як ZK-EVM та DAS).
Як взаємодіяти з іншими частинами дорожньої карти?
Якщо реалізувати стиснення даних, потреба в 2D DAS зменшиться, або принаймні затримається, якщо Plasma буде широко використовуватися, то потреба ще більше зменшиться. DAS також ставить виклики перед протоколами та механізмами побудови розподілених блоків: хоча DAS теоретично дружній до розподіленої реконструкції, на практиці це вимагає поєднання з пропозицією списку включення пакетів та механізмами вибору розгалуження навколо нього.
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Стиснення даних
Яку проблему ми вирішуємо?
Кожна транзакція в Rollup займає велику кількість місця в ланцюгу: передача ERC20 потребує приблизно 180 байт. Навіть за наявності ідеального зразка доступності даних це обмежує масштабованість Layer-протоколів. Кожен слот 16 МБ, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Що буде, якщо ми не тільки зможемо вирішити проблеми з чисельником, але й вирішимо проблеми з знаменником, щоб кожна транзакція в Rollup займала менше байтів в ланцюзі?
Що це таке і як це працює?
У нульових байтах стиснення, два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів. Далі ми використали специфічні властивості транзакцій:
Агрегація підписів: ми перейшли від підписів ECDSA до підписів BLS. Особливість підписів BLS полягає в тому, що кілька підписів можуть бути об'єднані в один єдиний підпис, який може підтвердити дійсність усіх оригінальних підписів. На рівні L1, оскільки навіть при агрегації обчислювальні витрати на верифікацію залишаються високими, тому використання підписів BLS не розглядається. Але в середовищі L2, де дані є дефіцитом, використання підписів BLS має сенс. Агрегаційна функція ERC-4337 забезпечує шлях для реалізації цієї можливості.
Замініть адреси на вказівники: якщо раніше використовувалася певна адреса, ми можемо замінити 20-байтову адресу на 4-байтовий вказівник, що вказує на певне місце в історії.
Кастомна серіалізація торгових значень------Більшість торгових значень мають невелику кількість знаків, наприклад, 0.25 Етер відображається як 250