Новий документ Віталіка: можливе майбутнє Ethereum, The Surge
Дорожня карта Ethereum спочатку включала дві стратегії масштабування: шардінг та протоколи Layer2. Ці два шляхи врешті-решт об'єдналися, утворивши дорожню карту, зосереджену на Rollup, яка досі є поточною стратегією розширення Ethereum. Дорожня карта, зосереджена на Rollup, пропонує простий розподіл обов'язків: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим шаром, тоді як L2 виконує завдання допомагати розширенню екосистеми.
Цього року дорожня карта, зосереджена на Rollup, досягла важливих результатів: з запуском блобів EIP-4844 суттєво збільшилася пропускна здатність даних Ethereum L1, кілька Ethereum Virtual Machine (EVM) Rollup перейшли до першої стадії. Кожен L2 існує як "шар" з власними внутрішніми правилами та логікою, різноманітність і різноманітність реалізації шарів тепер стали реальністю. Але, як ми бачимо, йти цим шляхом також стикається з деякими унікальними викликами. Тому наше нинішнє завдання - завершити дорожню карту, зосереджену на Rollup, і вирішити ці проблеми, зберігаючи при цьому стійкість і децентралізацію, притаманні Ethereum L1.
Зростання: ключова мета
У майбутньому Ethereum через L2 може досягти понад 100000 TPS;
Зберігайте децентралізацію та надійність L1;
Принаймні деякі L2 повністю успадкували основні властивості Ethereum (: довіра, відкритість, стійкість до цензури );
Ethereum повинен відчуватися як єдина екосистема, а не 34 різних блокчейнів.
Трикутник масштабованості — це ідея, яка була висунута в 2017 році, що вважає, що між трьома характеристиками блокчейну існує суперечність: децентралізація (, а саме: низька вартість роботи вузлів ), масштабованість (, кількість оброблюваних транзакцій ) та безпека (, оскільки зловмисник має знищити значну частину вузлів у мережі, щоб зробити одну транзакцію неуспішною ).
Варто зазначити, що трикутний парадокс не є теоремою, а публікації, що вводять трикутний парадокс, також не містять математичних доказів. Він дійсно надає евристичний математичний аргумент: якщо децентралізований дружній вузол (, наприклад, споживчий ноутбук ) може перевіряти 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 матиме 3 блоби обсягом приблизно 125 кБ на слот кожні 12 секунд, або доступну пропускну здатність даних приблизно 375 кБ на слот. Припустимо, що дані транзакцій публікуються безпосередньо в ланцюгу, тоді переказ ERC20 становитиме приблизно 180 байтів, отже максимальний TPS Rollup на Ethereum становитиме: 375000 / 12 / 180 = 173.6 TPS.
Якщо ми додамо теоретичне максимальне значення calldataEthereum(: кожен слот 30000000 Gas / за байт 16 gas = кожен слот 1,875,000 байт), то це становитиме 607 TPS. Використовуючи PeerDAS, кількість блобів може зрости до 8-16, що забезпечить для calldata 463-926 TPS.
Це значне поліпшення для Ethereum L1, але цього недостатньо. Ми хочемо більше масштабованості. Наша середньострокова мета – 16 МБ за слот, що в поєднанні з покращеннями стиснення даних Rollup принесе ~58000 TPS.
Що це? Як це працює?
PeerDAS є відносно простою реалізацією "1D sampling". В Ethereum кожен blob є 4096-м многочленом на 253-му простому полі (prime field). Ми транслюємо частини многочлена, де кожна частина містить 16 значень оцінювання з сусідніх 16 координат з загалом 8192 координат. З цих 8192 оцінок будь-які 4096 з ( відповідно до нинішніх запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, де i-та підмережа транслює будь-який blob i-го зразка, і запитує у глобальній p2p-мережі рівноправних учасників (, хто буде прослуховувати різні підмережі ), щоб отримати необхідні blob з інших підмереж. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до рівня однопартійних учасників. Поточна пропозиція полягає в тому, щоб учасники доказу частки використовували SubnetDAS, тоді як інші учасники (, тобто клієнти ), використовували PeerDAS.
З теоретичної точки зору, ми можемо розширити масштаб "1D sampling" досить суттєво: якщо ми збільшимо максимальну кількість blob до 256(, ставлячи за мету 128), тоді ми зможемо досягти цілі в 16MB, а в кожному вузлі в зразку доступності даних буде 16 зразків * 128 blob * по 512 байт на кожен blob на зразок = 1 MB пропускної спроможності даних на слот. Це лише ледь вписується в наші межі терпимості: це можливо, але це означає, що клієнти з обмеженою пропускною спроможністю не зможуть проводити зразки. Ми можемо оптимізувати цю ситуацію до певної міри, зменшуючи кількість blob і збільшуючи їхній розмір, але це підвищить витрати на відновлення.
Отже, в кінцевому підсумку ми хочемо зробити ще один крок вперед, здійснити 2D вибірку ( 2D sampling ), цей метод не тільки проводить випадкову вибірку всередині blob, але й між blob. Використовуючи лінійні властивості KZG зобов'язань, розширити набір blob у блоці за допомогою нового набору віртуальних blob, які надмірно кодують ту ж саму інформацію.
Отже, в кінцевому підсумку ми хочемо зробити ще один крок вперед і провести 2D-відібрання, яке відбувається не лише всередині blob, але й між blob. Лінійні властивості KZG-обіцянки використовуються для розширення набору blob у блоці, який містить новий список віртуальних blob з надмірним кодуванням однієї й тієї ж інформації.
Вкрай важливо, що розширення обіцянки не потребує наявності blob, тому це рішення в принципі є дружнім до розподіленого будівництва блоків. Фактичним вузлам, які будують блоки, потрібно лише мати blob KZG обіцянку, і вони можуть покладатися на зразки доступності даних (DAS) для перевірки доступності блоків даних. Одновимірні зразки доступності даних (1D DAS) в основному також є дружніми до розподіленого будівництва блоків.
( Що ще потрібно зробити? Які є компроміси?
Далі йдеться про завершення впровадження та запуску 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 займала менше байтів на ланцюзі, що тоді буде?
Що це таке, як це працює?
На мою думку, найкраще пояснення – це це зображення дворічної давності:
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск]###https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
У стисненні нульових байтів кожен довгий нульовий байтовий рядок замінюється на два байти, що вказують, скільки нульових байтів є. Далі ми скористалися специфічними властивостями транзакцій:
Підписна агрегація: ми перейшли від підпису ECDSA до підпису BLS. Особливістю підпису BLS є те, що кілька підписів можуть бути об'єднані в один єдиний підпис, який може підтверджувати дійсність усіх оригінальних підписів. На рівні L1, оскільки навіть при агрегації обчислювальні витрати на верифікацію залишаються високими, використання підпису BLS не розглядається. Але в середовищі L2, де дані є дефіцитом, використання підпису BLS має сенс. Агрегаційна функція ERC-4337 надає шлях для реалізації цієї функції.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Віталік про майбутнє Ethereum: як The Surge реалізує масштабування до 100 000 TPS
Новий документ Віталіка: можливе майбутнє Ethereum, The Surge
Дорожня карта Ethereum спочатку включала дві стратегії масштабування: шардінг та протоколи Layer2. Ці два шляхи врешті-решт об'єдналися, утворивши дорожню карту, зосереджену на Rollup, яка досі є поточною стратегією розширення Ethereum. Дорожня карта, зосереджена на Rollup, пропонує простий розподіл обов'язків: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим шаром, тоді як L2 виконує завдання допомагати розширенню екосистеми.
Цього року дорожня карта, зосереджена на Rollup, досягла важливих результатів: з запуском блобів EIP-4844 суттєво збільшилася пропускна здатність даних Ethereum L1, кілька Ethereum Virtual Machine (EVM) Rollup перейшли до першої стадії. Кожен L2 існує як "шар" з власними внутрішніми правилами та логікою, різноманітність і різноманітність реалізації шарів тепер стали реальністю. Але, як ми бачимо, йти цим шляхом також стикається з деякими унікальними викликами. Тому наше нинішнє завдання - завершити дорожню карту, зосереджену на Rollup, і вирішити ці проблеми, зберігаючи при цьому стійкість і децентралізацію, притаманні Ethereum L1.
Зростання: ключова мета
У майбутньому Ethereum через L2 може досягти понад 100000 TPS;
Зберігайте децентралізацію та надійність L1;
Принаймні деякі L2 повністю успадкували основні властивості Ethereum (: довіра, відкритість, стійкість до цензури );
Ethereum повинен відчуватися як єдина екосистема, а не 34 різних блокчейнів.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
Зміст розділу
Парадокс тріади масштабованості
Трикутник масштабованості — це ідея, яка була висунута в 2017 році, що вважає, що між трьома характеристиками блокчейну існує суперечність: децентралізація (, а саме: низька вартість роботи вузлів ), масштабованість (, кількість оброблюваних транзакцій ) та безпека (, оскільки зловмисник має знищити значну частину вузлів у мережі, щоб зробити одну транзакцію неуспішною ).
Варто зазначити, що трикутний парадокс не є теоремою, а публікації, що вводять трикутний парадокс, також не містять математичних доказів. Він дійсно надає евристичний математичний аргумент: якщо децентралізований дружній вузол (, наприклад, споживчий ноутбук ) може перевіряти N транзакцій за секунду, і у вас є ланцюг, що обробляє k*N транзакцій за секунду, тоді (i) кожна транзакція може бути побачена лише 1/k вузлом, що означає, що зловмисник може зламати лише кілька вузлів, щоб провести злочинну транзакцію, або (ii) ваші вузли стануть потужними, а ваш ланцюг не буде децентралізованим. Мета цієї статті зовсім не полягає в тому, щоб довести, що подолати трикутний парадокс неможливо; навпаки, вона має на меті продемонструвати, що подолати тривимірний парадокс важко, і це потребує певного виходу за межі мислення, передбаченого цим аргументом.
Протягом багатьох років деякі високопродуктивні ланцюги стверджували, що вони вирішили трійне парадокс без фундаментальних змін у архітектурі, зазвичай шляхом застосування технологій програмної інженерії для оптимізації вузлів. Це завжди є оманливим, оскільки запуск вузлів на цих ланцюгах значно складніший, ніж на Ethereum. У цій статті буде розглянуто, чому це так, і чому лише програмна інженерія L1-клієнтів не може розширити Ethereum?
Однак поєднання вибірки доступності даних та SNARKs дійсно вирішує трикутний парадокс: воно дозволяє клієнтам перевіряти, що певна кількість даних доступна, і що певна кількість обчислювальних кроків виконується правильно, завантажуючи лише невелику кількість даних і виконуючи дуже мало обчислень. SNARKs не потребують довіри. Вибірка доступності даних має тонку модель довіри few-of-N, але зберігає основні характеристики, притаманні нездатним до масштабування ланцюгам, а саме, що навіть атака на 51% не може примусити погані блоки бути прийнятими мережею.
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Іншим способом вирішення трьох проблем є архітектура Plasma, яка використовує хитрі технології, щоб заохочувати відповідальність за доступність даних спостереження користувачами. Ще в 2017-2019 роках, коли у нас був лише засіб шахрайських доказів для розширення обчислювальних можливостей, Plasma була дуже обмежена в безпечному виконанні, але з поширенням SNARKs( нульових знань, стиснених, неінтерактивних доказів), архітектура Plasma стала більш життєздатною для набагато ширшого кола сценаріїв використання, ніж коли-небудь.
Подальший прогрес у вибірці доступності даних
Яку проблему ми вирішуємо?
13 березня 2024 року, коли оновлення Dencun буде запущено, блокчейн Ethereum матиме 3 блоби обсягом приблизно 125 кБ на слот кожні 12 секунд, або доступну пропускну здатність даних приблизно 375 кБ на слот. Припустимо, що дані транзакцій публікуються безпосередньо в ланцюгу, тоді переказ ERC20 становитиме приблизно 180 байтів, отже максимальний TPS Rollup на Ethereum становитиме: 375000 / 12 / 180 = 173.6 TPS.
Якщо ми додамо теоретичне максимальне значення calldataEthereum(: кожен слот 30000000 Gas / за байт 16 gas = кожен слот 1,875,000 байт), то це становитиме 607 TPS. Використовуючи PeerDAS, кількість блобів може зрости до 8-16, що забезпечить для calldata 463-926 TPS.
Це значне поліпшення для Ethereum L1, але цього недостатньо. Ми хочемо більше масштабованості. Наша середньострокова мета – 16 МБ за слот, що в поєднанні з покращеннями стиснення даних Rollup принесе ~58000 TPS.
Що це? Як це працює?
PeerDAS є відносно простою реалізацією "1D sampling". В Ethereum кожен blob є 4096-м многочленом на 253-му простому полі (prime field). Ми транслюємо частини многочлена, де кожна частина містить 16 значень оцінювання з сусідніх 16 координат з загалом 8192 координат. З цих 8192 оцінок будь-які 4096 з ( відповідно до нинішніх запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, де i-та підмережа транслює будь-який blob i-го зразка, і запитує у глобальній p2p-мережі рівноправних учасників (, хто буде прослуховувати різні підмережі ), щоб отримати необхідні blob з інших підмереж. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до рівня однопартійних учасників. Поточна пропозиція полягає в тому, щоб учасники доказу частки використовували SubnetDAS, тоді як інші учасники (, тобто клієнти ), використовували PeerDAS.
З теоретичної точки зору, ми можемо розширити масштаб "1D sampling" досить суттєво: якщо ми збільшимо максимальну кількість blob до 256(, ставлячи за мету 128), тоді ми зможемо досягти цілі в 16MB, а в кожному вузлі в зразку доступності даних буде 16 зразків * 128 blob * по 512 байт на кожен blob на зразок = 1 MB пропускної спроможності даних на слот. Це лише ледь вписується в наші межі терпимості: це можливо, але це означає, що клієнти з обмеженою пропускною спроможністю не зможуть проводити зразки. Ми можемо оптимізувати цю ситуацію до певної міри, зменшуючи кількість blob і збільшуючи їхній розмір, але це підвищить витрати на відновлення.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
Отже, в кінцевому підсумку ми хочемо зробити ще один крок вперед, здійснити 2D вибірку ( 2D sampling ), цей метод не тільки проводить випадкову вибірку всередині blob, але й між blob. Використовуючи лінійні властивості KZG зобов'язань, розширити набір blob у блоці за допомогою нового набору віртуальних blob, які надмірно кодують ту ж саму інформацію.
Отже, в кінцевому підсумку ми хочемо зробити ще один крок вперед і провести 2D-відібрання, яке відбувається не лише всередині blob, але й між blob. Лінійні властивості KZG-обіцянки використовуються для розширення набору blob у блоці, який містить новий список віртуальних blob з надмірним кодуванням однієї й тієї ж інформації.
Вкрай важливо, що розширення обіцянки не потребує наявності blob, тому це рішення в принципі є дружнім до розподіленого будівництва блоків. Фактичним вузлам, які будують блоки, потрібно лише мати blob KZG обіцянку, і вони можуть покладатися на зразки доступності даних (DAS) для перевірки доступності блоків даних. Одновимірні зразки доступності даних (1D DAS) в основному також є дружніми до розподіленого будівництва блоків.
( Що ще потрібно зробити? Які є компроміси?
Далі йдеться про завершення впровадження та запуску 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 теоретично дружній до розподіленого відновлення, на практиці це потребує поєднання з пропозицією списку включення пакетів та механізмами вибору розгалуження навколо нього.
Стиснення даних
) Яку проблему ми вирішуємо?
Кожна транзакція в Rollup займає велику кількість даних на блокчейні: передача ERC20 потребує приблизно 180 байт. Навіть за ідеальної доступності даних це обмежує масштабованість Layer-протоколів. Кожен слот 16 МБ, отже, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Якщо ми зможемо вирішити не лише проблеми з чисельником, але й з знаменником, і зробити так, щоб кожна транзакція в Rollup займала менше байтів на ланцюзі, що тоді буде?
Що це таке, як це працює?
На мою думку, найкраще пояснення – це це зображення дворічної давності:
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск]###https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
У стисненні нульових байтів кожен довгий нульовий байтовий рядок замінюється на два байти, що вказують, скільки нульових байтів є. Далі ми скористалися специфічними властивостями транзакцій:
Підписна агрегація: ми перейшли від підпису ECDSA до підпису BLS. Особливістю підпису BLS є те, що кілька підписів можуть бути об'єднані в один єдиний підпис, який може підтверджувати дійсність усіх оригінальних підписів. На рівні L1, оскільки навіть при агрегації обчислювальні витрати на верифікацію залишаються високими, використання підпису BLS не розглядається. Але в середовищі L2, де дані є дефіцитом, використання підпису BLS має сенс. Агрегаційна функція ERC-4337 надає шлях для реалізації цієї функції.
використовувати