Стратегії масштабування Ethereum спочатку мали два напрямки: шардінг і Layer2 протоколи. Шардінг дозволяє кожному вузлу перевіряти та зберігати лише частину транзакцій, тоді як Layer2 будує мережу поверх Ethereum. Ці дві стратегії врешті-решт об'єдналися, сформувавши дорожню карту, зосереджену на Rollup, яка залишається стратегією масштабування Ethereum до сьогодні.
Дорожня карта, зосереджена на Rollup, пропонує простий розподіл праці: Ethereum L1 зосереджується на створенні потужного та децентралізованого базового шару, тоді як L2 виконує завдання допомоги в розширенні екосистеми. Ця модель широко поширена в суспільстві, як, наприклад, система судів (L1), що захищає контракти та власницькі права, а підприємці (L2) будують на цій основі.
Цього року важливі досягнення були досягнуті в дорожній карті, зосередженій на Rollup: EIP-4844 blobs значно збільшили пропускну спроможність даних Ethereum L1, кілька Rollup для Ethereum Virtual Machine перейшли до першої стадії. Кожен L2 існує як "шар" з власними правилами та логікою, різноманітність способів реалізації шарів стала реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наша теперішня задача полягає в завершенні дорожньої карти, зосередженої на Rollup, вирішуючи ці проблеми, водночас зберігаючи стійкість та децентралізацію Ethereum L1.
Зростання: ключова мета
У майбутньому Ethereum через L2 зможе досягти більше 100000 TPS;
Зберігати децентралізацію та надійність L1;
Принаймні деякі L2 повністю успадковують основні властивості Ethereum ( для довіри, відкритості, стійкості до цензури );
Ethereum має відчуватися як єдина екосистема, а не 34 різні блокчейни.
Трикутник суперечностей масштабованості вважає, що між трьома характеристиками блокчейну існує суперечність: децентралізація ( витрати на робочі вузли низькі ), масштабованість ( обробка великої кількості транзакцій ) та безпека ( зловмисник повинен знищити велику частину вузлів, щоб викликати невдачу окремої транзакції ).
Трикутний парадокс не є теоремою, пост, що його представляє, також не містить математичного доведення. Він наводить евристичні аргументи: якщо децентралізовані дружні вузли можуть перевіряти 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 на Ethereum Rollup становитиме: 375000 / 12 / 180 = 173.6 TPS
Додавши до теорійного максимального значення calldata Ethereum (: на кожен слот 30 мільйонів Gas / на байт 16 gas = на кожен слот 1,875,000 байтів ), це призведе до 607 TPS. Використовуючи PeerDAS, кількість blob може зрости до 8-16, що забезпечить 463-926 TPS для calldata.
Це значне покращення для 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 МБ даних на слот. Це ледь вписується в межі терпимості: можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть виконувати вибірку. Ми можемо оптимізувати, зменшивши кількість blob і збільшивши їх розмір, але це призведе до підвищення витрат на відновлення.
Тому ми врешті-решт хочемо зробити ще один крок вперед і провести 2D-отримання вибірки, яке не лише випадково вибирає з blob, а й між blob. Використовуючи лінійні властивості KZG-обіцянки, розширити набір blob у блоці за допомогою нового віртуального набору blob, ці віртуальні blob кодують ту ж саму інформацію.
Важливо, що обчислення зобов'язань не потребує наявності blob, тому це рішення в основному є дружнім до розподіленого будівництва блоків. Фактичним вузлам, які будують блоки, потрібно лише мати KZG-зобов'язання blob, на які вони можуть покладатися для перевірки доступності даних за допомогою вибірки доступності даних. Одновимірна вибірка доступності даних також в основному є дружньою до розподіленого будівництва блоків.
Далі йдеться про завершення впровадження та запуску 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 ETH представляється як 250,000,000,000,000,000 wei. Максимальні базові комісії та пріоритетні комісії також подібні. Тому ми можемо використовувати кастомізований десятковий формат з плаваючою комою для представлення більшості валютних значень.
що ще потрібно зробити, які є компроміси?
Далі основне, що потрібно зробити, це фактично реалізувати вищезгаданий план. Основні компроміси включають:
Перехід на підпис BLS вимагатиме великих зусиль і знизить сумісність з надійними апаратними чіпами, що підвищують безпеку. Можна використовувати упаковку ZK-SNARK з іншими схемами підпису як альтернативу.
Динамічне стиснення ( Наприклад, заміна адреси ) на вказівники ускладнить код клієнта.
Публікація різниці стану в ланцюг замість транзакції знизить аудиторську здатність, що зробить багато програм (, таких як блокчейн-браузери ), нездатними працювати.
Як взаємодіяти з іншими частинами дорожньої карти?
використовуючи ERC-4337, і в кінцевому підсумку включивши частину його змісту
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
24 лайків
Нагородити
24
6
Поділіться
Прокоментувати
0/400
LongTermDreamer
· 07-22 01:04
Через три роки всім доведеться дивитися на обличчя нашого L2, накопичувати трохи не зашкодить.
Переглянути оригіналвідповісти на0
alpha_leaker
· 07-19 10:23
В булрані треба використовувати L2, щоб заробляти.
Переглянути оригіналвідповісти на0
GasDevourer
· 07-19 01:26
Не зрозумів L2 - втратив труси!
Переглянути оригіналвідповісти на0
TrustlessMaximalist
· 07-19 01:21
Rollup справді чудовий, увійти в позицію - це правильно.
Переглянути оригіналвідповісти на0
consensus_whisperer
· 07-19 01:11
Коли можна досягти 100 тис. TPS, скажіть точно.
Переглянути оригіналвідповісти на0
GateUser-3824aa38
· 07-19 01:10
Крутити знову і знову, все ж таки Біткойн найкраще працює.
Ethereum розширення: аналіз The Surge та перспективи розвитку L2
Ethereum можливе майбутнє: The Surge
Стратегії масштабування Ethereum спочатку мали два напрямки: шардінг і Layer2 протоколи. Шардінг дозволяє кожному вузлу перевіряти та зберігати лише частину транзакцій, тоді як Layer2 будує мережу поверх Ethereum. Ці дві стратегії врешті-решт об'єдналися, сформувавши дорожню карту, зосереджену на Rollup, яка залишається стратегією масштабування Ethereum до сьогодні.
Дорожня карта, зосереджена на Rollup, пропонує простий розподіл праці: Ethereum L1 зосереджується на створенні потужного та децентралізованого базового шару, тоді як L2 виконує завдання допомоги в розширенні екосистеми. Ця модель широко поширена в суспільстві, як, наприклад, система судів (L1), що захищає контракти та власницькі права, а підприємці (L2) будують на цій основі.
Цього року важливі досягнення були досягнуті в дорожній карті, зосередженій на Rollup: EIP-4844 blobs значно збільшили пропускну спроможність даних Ethereum L1, кілька Rollup для Ethereum Virtual Machine перейшли до першої стадії. Кожен L2 існує як "шар" з власними правилами та логікою, різноманітність способів реалізації шарів стала реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наша теперішня задача полягає в завершенні дорожньої карти, зосередженої на Rollup, вирішуючи ці проблеми, водночас зберігаючи стійкість та децентралізацію Ethereum L1.
Зростання: ключова мета
! Віталік Нова стаття: Можливе майбутнє 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 на Ethereum Rollup становитиме: 375000 / 12 / 180 = 173.6 TPS
Додавши до теорійного максимального значення calldata Ethereum (: на кожен слот 30 мільйонів Gas / на байт 16 gas = на кожен слот 1,875,000 байтів ), це призведе до 607 TPS. Використовуючи PeerDAS, кількість blob може зрости до 8-16, що забезпечить 463-926 TPS для calldata.
Це значне покращення для 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 МБ даних на слот. Це ледь вписується в межі терпимості: можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть виконувати вибірку. Ми можемо оптимізувати, зменшивши кількість blob і збільшивши їх розмір, але це призведе до підвищення витрат на відновлення.
Тому ми врешті-решт хочемо зробити ще один крок вперед і провести 2D-отримання вибірки, яке не лише випадково вибирає з blob, а й між blob. Використовуючи лінійні властивості KZG-обіцянки, розширити набір blob у блоці за допомогою нового віртуального набору blob, ці віртуальні blob кодують ту ж саму інформацію.
Важливо, що обчислення зобов'язань не потребує наявності blob, тому це рішення в основному є дружнім до розподіленого будівництва блоків. Фактичним вузлам, які будують блоки, потрібно лише мати KZG-зобов'язання blob, на які вони можуть покладатися для перевірки доступності даних за допомогою вибірки доступності даних. Одновимірна вибірка доступності даних також в основному є дружньою до розподіленого будівництва блоків.
! Віталік Нова стаття: Можливе майбутнє 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 займатиме менше байтів на ланцюзі, що буде?
Що це таке, як це працює?
На мою думку, найкраще пояснення – це зображення двирічної давності:
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
У нульовій байтовій компресії два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів. Далі ми використали специфічні властивості транзакцій:
Агрегація підписів: ми перейшли від підписів ECDSA до підписів BLS. Особливістю підписів BLS є можливість комбінувати кілька підписів в один, цей підпис може довести дійсність всіх оригінальних підписів. На рівні L1, навіть при агрегації, вартість обчислень для верифікації залишається високою, тому використання підписів BLS не розглядається. Але в середовищі L2, де даних обмаль, використання підписів BLS має сенс. Агрегуюча функція ERC-4337 забезпечує шлях для реалізації цієї можливості.
Замініть адреси на вказівники: якщо раніше використовувалася певна адреса, ми можемо замінити 20-байтову адресу на 4-байтовий вказівник, що вказує на певну позицію в історії.
Кастомізоване серіалізування торгових значень: більшість торгових значень мають невелику кількість розрядів, наприклад, 0.25 ETH представляється як 250,000,000,000,000,000 wei. Максимальні базові комісії та пріоритетні комісії також подібні. Тому ми можемо використовувати кастомізований десятковий формат з плаваючою комою для представлення більшості валютних значень.
що ще потрібно зробити, які є компроміси?
Далі основне, що потрібно зробити, це фактично реалізувати вищезгаданий план. Основні компроміси включають:
Перехід на підпис BLS вимагатиме великих зусиль і знизить сумісність з надійними апаратними чіпами, що підвищують безпеку. Можна використовувати упаковку ZK-SNARK з іншими схемами підпису як альтернативу.
Динамічне стиснення ( Наприклад, заміна адреси ) на вказівники ускладнить код клієнта.
Публікація різниці стану в ланцюг замість транзакції знизить аудиторську здатність, що зробить багато програм (, таких як блокчейн-браузери ), нездатними працювати.
Як взаємодіяти з іншими частинами дорожньої карти?
використовуючи ERC-4337, і в кінцевому підсумку включивши частину його змісту