У дорожній карті Ethereum спочатку було два стратегії масштабування: шардінг та Layer2 протоколи. Ці два шляхи зрештою об'єдналися, сформувавши дорожню карту, зосереджену на Rollup, яка досі залишається стратегією розширення Ethereum. Дорожня карта, зосереджена на Rollup, пропонує простий поділ праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим шаром, тоді як L2 виконує завдання допомоги в розширенні екосистеми.
Цього року дорожня карта, що зосереджена на Rollup, досягла важливих результатів: з випуском блобів EIP-4844 значно збільшилася пропускна здатність даних Ethereum L1, кілька Ethereum віртуальних машин (EVM) Rollup перейшли в першу стадію. Кожен L2 існує як "шар" з власними внутрішніми правилами та логікою, різноманітність і різноманітність способів реалізації шарів тепер стали реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наша теперішня задача полягає в завершенні дорожньої карти, зосередженої на Rollup, і вирішенні цих проблем, одночасно підтримуючи характерну надійність і децентралізацію Ethereum L1.
The Surge: ключова мета
У майбутньому 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 матиме 3 блоби приблизно по 125 кБ на кожен слот кожні 12 секунд, або приблизно 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-ї кількості ( prime field ). Ми транслюємо частки многочлена, де кожна частка містить 16 оцінок на сусідніх 16 координатах з загалом 8192 координат. У цих 8192 оцінках будь-які 4096 з ( відповідно до теперішніх запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, в яких i-та підмережа транслює i-й зразок будь-якого blob, і запитує у глобальному p2p-мережі однорангових рівняння (, хто прослухає різні підмережі ), щоб запитати інші blob з підмереж, які йому потрібні. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до однорангового рівняння. Поточна пропозиція полягає в тому, щоб дозволити вузлам, що беруть участь у механізмі доказу частки, використовувати SubnetDAS, тоді як інші вузли (, тобто клієнти ), використовують PeerDAS.
Теоретично, ми можемо масштабувати «1D sampling» до досить великого розміру: якщо ми збільшимо максимальну кількість blob до 256( з метою 128), то ми зможемо досягти цілі в 16 МБ, а доступність даних у зразках для кожного вузла становитиме 16 зразків * 128 blob * кожен blob по 512 байт = 1 МБ пропускної спроможності даних на слот. Це ледь укладається в наші межі терпимості: це можливо, але це означає, що клієнти з обмеженою пропускною спроможністю не зможуть брати участь у зразках. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob і збільшуючи їхній розмір, але це призведе до підвищення витрат на відновлення.
Отже, ми врешті-решт хочемо зробити ще один крок вперед, провести 2D вибірку (2D sampling), цей метод не тільки проводить випадкову вибірку всередині блобу, але й між блобами. Використовуючи лінійні властивості KZG-комітменту, розширюємо набір блобів в блоці за допомогою нової групи віртуальних блобів, які надмірно кодують ту ж інформацію.
Тому в кінцевому підсумку ми хочемо зробити ще один крок вперед, здійснити 2D-відібрання, яке проводиться не лише всередині blob, але й між blob. Лінійні властивості KZG-комітментів використовуються для розширення набору 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 теоретично дружній до розподіленого відновлення, на практиці це вимагає поєднання з пропозицією списку включення пакетів та механізмами вибору форків навколо нього.
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
Стиснення даних
( Яку проблему ми вирішуємо?
Кожна транзакція в Rollup займає велику кількість простору даних на ланцюгу: передача ERC20 потребує приблизно 180 байт. Навіть за наявності ідеальної вибірки даних це обмежує масштабованість протоколів Layer. Кожен слот 16 МБ, отже ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Що буде, якщо ми зможемо вирішити не лише проблеми чисельника, але й проблеми знаменника, дозволивши кожній транзакції в Rollup займати менше байтів в ланцюзі?
) Що це таке і як це працює?
На мій погляд, найкращим поясненням є ця картинка дворічної давності:
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
У нульових байтах стискання, два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів. Далі ми скористалися певними властивостями транзакцій:
Підписна агрегація: ми перейшли від підписів ECDSA до підписів BLS. Ознакою підписів BLS є те, що кілька підписів можуть об'єднуватися в один єдиний підпис, який може підтвердити дійсність усіх оригінальних підписів. На рівні L1, навіть при агрегації, обчислювальна вартість верифікації залишається високою, тому використання підписів BLS не розглядається. Але в середовищі L2, де даних недостатньо, використання підписів BLS є доцільним. Агрегатна характеристика ERC-4337 забезпечує шлях для реалізації цієї функції.
Замініть адресу на вказівники: якщо ви раніше використовували якусь адресу, ми можемо замінити 20-байтову адресу на 4-байтовий вказівник, що вказує на певне місце в історії.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
19 лайків
Нагородити
19
9
Поділіться
Прокоментувати
0/400
HashBard
· 07-19 15:02
сер... роллапи це як поезія в русі fr fr. бичачий на цьому ривку наративу ngl
Ethereum The Surge: Розширена стратегія на основі Rollup
Ethereum можливе майбутнє: The Surge
У дорожній карті Ethereum спочатку було два стратегії масштабування: шардінг та Layer2 протоколи. Ці два шляхи зрештою об'єдналися, сформувавши дорожню карту, зосереджену на Rollup, яка досі залишається стратегією розширення Ethereum. Дорожня карта, зосереджена на Rollup, пропонує простий поділ праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим шаром, тоді як L2 виконує завдання допомоги в розширенні екосистеми.
Цього року дорожня карта, що зосереджена на Rollup, досягла важливих результатів: з випуском блобів EIP-4844 значно збільшилася пропускна здатність даних Ethereum L1, кілька Ethereum віртуальних машин (EVM) Rollup перейшли в першу стадію. Кожен L2 існує як "шар" з власними внутрішніми правилами та логікою, різноманітність і різноманітність способів реалізації шарів тепер стали реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наша теперішня задача полягає в завершенні дорожньої карти, зосередженої на Rollup, і вирішенні цих проблем, одночасно підтримуючи характерну надійність і децентралізацію Ethereum L1.
The Surge: ключова мета
У майбутньому Ethereum через L2 може досягти понад 100000 TPS;
Зберегти децентралізацію та надійність L1;
Принаймні деякі L2 повністю успадкували основні властивості Ethereum ( довіри, відкритості, антицензури );
Ethereum повинен відчуватися як єдина екосистема, а не 34 різні блокчейни.
! Віталік Новини: Можливе майбутнє 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 матиме 3 блоби приблизно по 125 кБ на кожен слот кожні 12 секунд, або приблизно 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-ї кількості ( prime field ). Ми транслюємо частки многочлена, де кожна частка містить 16 оцінок на сусідніх 16 координатах з загалом 8192 координат. У цих 8192 оцінках будь-які 4096 з ( відповідно до теперішніх запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, в яких i-та підмережа транслює i-й зразок будь-якого blob, і запитує у глобальному p2p-мережі однорангових рівняння (, хто прослухає різні підмережі ), щоб запитати інші blob з підмереж, які йому потрібні. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до однорангового рівняння. Поточна пропозиція полягає в тому, щоб дозволити вузлам, що беруть участь у механізмі доказу частки, використовувати SubnetDAS, тоді як інші вузли (, тобто клієнти ), використовують PeerDAS.
Теоретично, ми можемо масштабувати «1D sampling» до досить великого розміру: якщо ми збільшимо максимальну кількість blob до 256( з метою 128), то ми зможемо досягти цілі в 16 МБ, а доступність даних у зразках для кожного вузла становитиме 16 зразків * 128 blob * кожен blob по 512 байт = 1 МБ пропускної спроможності даних на слот. Це ледь укладається в наші межі терпимості: це можливо, але це означає, що клієнти з обмеженою пропускною спроможністю не зможуть брати участь у зразках. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob і збільшуючи їхній розмір, але це призведе до підвищення витрат на відновлення.
Отже, ми врешті-решт хочемо зробити ще один крок вперед, провести 2D вибірку (2D sampling), цей метод не тільки проводить випадкову вибірку всередині блобу, але й між блобами. Використовуючи лінійні властивості KZG-комітменту, розширюємо набір блобів в блоці за допомогою нової групи віртуальних блобів, які надмірно кодують ту ж інформацію.
Тому в кінцевому підсумку ми хочемо зробити ще один крок вперед, здійснити 2D-відібрання, яке проводиться не лише всередині blob, але й між blob. Лінійні властивості KZG-комітментів використовуються для розширення набору blob у блоці, що містить новий список віртуальних blob з надмірним кодуванням для однієї й тієї ж інформації.
Вкрай важливо, що обчислення зобов'язання на розширення не потребує блобу, тому це рішення в основному є дружнім до розподіленого будування блоків. Фактичні вузли, що будують блоки, повинні мати лише блоб KZG зобов'язання, і вони можуть покладатися на вибірку доступності даних (DAS) для перевірки доступності блоків даних. Одновимірна вибірка доступності даних (1D DAS) в основному також є дружньою до розподіленого будування блоків.
! Віталік Новини: Можливе майбутнє 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, сплеск])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
Стиснення даних
( Яку проблему ми вирішуємо?
Кожна транзакція в Rollup займає велику кількість простору даних на ланцюгу: передача ERC20 потребує приблизно 180 байт. Навіть за наявності ідеальної вибірки даних це обмежує масштабованість протоколів Layer. Кожен слот 16 МБ, отже ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Що буде, якщо ми зможемо вирішити не лише проблеми чисельника, але й проблеми знаменника, дозволивши кожній транзакції в Rollup займати менше байтів в ланцюзі?
) Що це таке і як це працює?
На мій погляд, найкращим поясненням є ця картинка дворічної давності:
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
У нульових байтах стискання, два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів. Далі ми скористалися певними властивостями транзакцій:
Підписна агрегація: ми перейшли від підписів ECDSA до підписів BLS. Ознакою підписів BLS є те, що кілька підписів можуть об'єднуватися в один єдиний підпис, який може підтвердити дійсність усіх оригінальних підписів. На рівні L1, навіть при агрегації, обчислювальна вартість верифікації залишається високою, тому використання підписів BLS не розглядається. Але в середовищі L2, де даних недостатньо, використання підписів BLS є доцільним. Агрегатна характеристика ERC-4337 забезпечує шлях для реалізації цієї функції.
Замініть адресу на вказівники: якщо ви раніше використовували якусь адресу, ми можемо замінити 20-байтову адресу на 4-байтовий вказівник, що вказує на певне місце в історії.
Користувацька послідовність значення транзакції