Дорожня карта Ethereum спочатку містила дві стратегії масштабування: шардінг та протоколи Layer2. Шардінг дозволяє кожному вузлу перевіряти та зберігати лише частину транзакцій, тоді як Layer2 будує мережу поверх Ethereum, використовуючи його безпеку, але зберігаючи більшість даних та обчислень поза основним ланцюгом. Ці два підходи врешті-решт об'єдналися в дорожню карту, зосереджену на Rollup, яка й досі є стратегією масштабування Ethereum.
Дорожня карта, зосереджена на Rollup, пропонує простий поділ праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим рівнем, тоді як L2 виконує завдання допомоги в розширенні екосистеми. Ця модель дуже поширена в суспільстві: судова система (L1) існує для захисту контрактів і власницьких прав, тоді як підприємці (L2) будують на цій основі, сприяючи розвитку людства.
Цього року дорожня карта, орієнтована на Rollup, досягла важливих успіхів: випуск EIP-4844 блобів значно збільшив пропускну здатність даних Ethereum L1, кілька Ethereum Virtual Machine (EVM) Rollup вже перейшли до першої стадії. Кожен L2 існує як "шар" з власними правилами та логікою, різноманітність способів реалізації шарів тепер стала реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наша теперішня задача - завершити дорожню карту, орієнтовану на Rollup, вирішити ці проблеми, зберігаючи при цьому стійкість та децентралізацію Ethereum L1.
Трикутник масштабованості стверджує, що існує суперечність між трьома характеристиками блокчейну: децентралізація (, низька вартість роботи вузлів ), масштабованість ( для обробки великої кількості транзакцій ) та безпека (, оскільки зловмиснику потрібно знищити велику частину вузлів у мережі, щоб спричинити невдачу однієї транзакції ).
Трикутний парадокс не є теоремою, а допис, що його представляє, також не містить математичного доведення. Він наводить евристичний математичний аргумент: якщо децентралізований дружній вузол може перевіряти N транзакцій за секунду, а у вас є ланцюг, що обробляє k*N транзакцій за секунду, тоді: (i) кожна транзакція може бути видима лише 1/k вузлам, що означає, що зловмиснику достатньо знищити кілька вузлів, щоб провести шкідливу транзакцію, або (ii) ваші вузли стануть потужними, а ваш ланцюг не стане децентралізованим. Ця стаття має на меті показати, що подолати трилему важко, і для цього потрібно в певному сенсі вийти за межі мисленнєвих рамок, що містять цей аргумент.
Протягом багатьох років деякі високопродуктивні блокчейни стверджують, що вони вирішили трійний парадокс без кардинальної зміни архітектури, зазвичай через оптимізацію вузлів. Це завжди є оманливим, оскільки запуск вузлів на цих блокчейнах набагато складніший, ніж на Ethereum.
Однак поєднання семплювання доступності даних і SNARK-ів дійсно вирішує трикутний парадокс: це дозволяє клієнтам перевіряти певну кількість даних на наявність, завантажуючи лише невелику кількість даних і виконуючи дуже мало обчислень, а також підтверджувати, що певна кількість обчислювальних кроків виконана правильно. SNARK-и є бездоверчими. Семплювання доступності даних має тонку модель довіри 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-м многочленом у полі простих чисел (prime field). Ми транслюємо частки многочлена, де кожна частка містить 16 значень оцінки з сусідніх 16 координат з загалом 8192 координат. Серед цих 8192 значень оцінки, будь-які 4096 з ( відповідно до поточних запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт слухав невелику кількість підмереж, де i-та підмережа транслює i-й зразок будь-якого блобу, та запитує у глобальних p2p-мережах рівноправних (, хто буде слухати різні підмережі ), щоб запитати інші блоби з необхідних підмереж. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до рівня рівноправних. Поточна пропозиція полягає в тому, щоб учасники підтвердження частки (staking) використовували SubnetDAS, тоді як інші вузли (, тобто клієнти ), використовували PeerDAS.
З теоретичної точки зору, ми можемо значно розширити масштаб "1D sampling": якщо ми збільшимо максимальну кількість blob до 256( з метою 128), тоді ми зможемо досягти цілі в 16 МБ, а у зразках доступності даних кожен вузол отримає 16 зразків * 128 blob * 512 байт на кожен blob за кожен зразок = 1 МБ пропускної здатності даних на кожен слот. Це лише з натяжкою вписується в наші межі терпимості: це здійсненно, але це означає, що клієнти з обмеженою пропускною здатністю не можуть виконувати зразки. Ми можемо оптимізувати це певною мірою, зменшуючи кількість 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 теоретично є дружнім до розподіленого відновлення, на практиці це вимагає поєднання з пропозицією списку включення пакетів та механізмами вибору розгалуження навколо них.
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp###
Стиснення даних
( Яку проблему ми вирішуємо?
Кожна транзакція в Rollup займає значний обсяг даних на ланцюгу: передача ERC20 потребує близько 180 байтів. Навіть за ідеальної доступності даних це обмежує масштабованість Layer-протоколів. Кожен слот 16 МБ, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Якщо ми зможемо вирішити не лише проблеми з чисельником, а й проблеми з знаменником, і зробити так, щоб кожна транзакція в Rollup займала менше байтів у ланцюгу, що тоді буде?
) Що це таке, як це працює?
На мою думку, найкраще пояснення - це це зображення дворічної давності:
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск]###https://img-cdn.gateio.im/webp-social/moments-a04daca8af5d6af3c06b77a97aae477d.webp###
У нульовій байтовій компресії, два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів є. Далі ми використали специфічні властивості транзакцій:
Агрегація підписів: ми перейшли від підпису ECDSA до підпису BLS. Особливістю підпису BLS є те, що кілька підписів можуть бути об'єднані в один єдиний підпис, який може підтвердити всі оригінальні.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
6 лайків
Нагородити
6
4
Поділіться
Прокоментувати
0/400
FloorSweeper
· 08-04 04:06
Не питайте чому, L2 просто класний
Переглянути оригіналвідповісти на0
RamenDeFiSurvivor
· 08-04 04:05
Валет L2 дійсно смачний
Переглянути оригіналвідповісти на0
ShadowStaker
· 08-04 04:02
гм, ефективність mev на l2s все ще потребує роботи, чесно кажучи... топологія мережі ще не зовсім готова
Переглянути оригіналвідповісти на0
BearMarketBuyer
· 08-04 03:59
Лише другий рівень чи вільний? Ми просто подивимося.
Ethereum розширення нової стадії: Глибина аналізу маршруту The Surge
Ethereum можливе майбутнє: The Surge
Дорожня карта Ethereum спочатку містила дві стратегії масштабування: шардінг та протоколи Layer2. Шардінг дозволяє кожному вузлу перевіряти та зберігати лише частину транзакцій, тоді як Layer2 будує мережу поверх Ethereum, використовуючи його безпеку, але зберігаючи більшість даних та обчислень поза основним ланцюгом. Ці два підходи врешті-решт об'єдналися в дорожню карту, зосереджену на Rollup, яка й досі є стратегією масштабування Ethereum.
Дорожня карта, зосереджена на Rollup, пропонує простий поділ праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим рівнем, тоді як L2 виконує завдання допомоги в розширенні екосистеми. Ця модель дуже поширена в суспільстві: судова система (L1) існує для захисту контрактів і власницьких прав, тоді як підприємці (L2) будують на цій основі, сприяючи розвитку людства.
Цього року дорожня карта, орієнтована на Rollup, досягла важливих успіхів: випуск EIP-4844 блобів значно збільшив пропускну здатність даних Ethereum L1, кілька Ethereum Virtual Machine (EVM) Rollup вже перейшли до першої стадії. Кожен L2 існує як "шар" з власними правилами та логікою, різноманітність способів реалізації шарів тепер стала реальністю. Але цей шлях також стикається з деякими унікальними викликами. Наша теперішня задача - завершити дорожню карту, орієнтовану на Rollup, вирішити ці проблеми, зберігаючи при цьому стійкість та децентралізацію Ethereum L1.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
Вибух: ключова ціль
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Парадокс тріangles可扩展ності
Трикутник масштабованості стверджує, що існує суперечність між трьома характеристиками блокчейну: децентралізація (, низька вартість роботи вузлів ), масштабованість ( для обробки великої кількості транзакцій ) та безпека (, оскільки зловмиснику потрібно знищити велику частину вузлів у мережі, щоб спричинити невдачу однієї транзакції ).
Трикутний парадокс не є теоремою, а допис, що його представляє, також не містить математичного доведення. Він наводить евристичний математичний аргумент: якщо децентралізований дружній вузол може перевіряти N транзакцій за секунду, а у вас є ланцюг, що обробляє k*N транзакцій за секунду, тоді: (i) кожна транзакція може бути видима лише 1/k вузлам, що означає, що зловмиснику достатньо знищити кілька вузлів, щоб провести шкідливу транзакцію, або (ii) ваші вузли стануть потужними, а ваш ланцюг не стане децентралізованим. Ця стаття має на меті показати, що подолати трилему важко, і для цього потрібно в певному сенсі вийти за межі мисленнєвих рамок, що містять цей аргумент.
Протягом багатьох років деякі високопродуктивні блокчейни стверджують, що вони вирішили трійний парадокс без кардинальної зміни архітектури, зазвичай через оптимізацію вузлів. Це завжди є оманливим, оскільки запуск вузлів на цих блокчейнах набагато складніший, ніж на Ethereum.
Однак поєднання семплювання доступності даних і SNARK-ів дійсно вирішує трикутний парадокс: це дозволяє клієнтам перевіряти певну кількість даних на наявність, завантажуючи лише невелику кількість даних і виконуючи дуже мало обчислень, а також підтверджувати, що певна кількість обчислювальних кроків виконана правильно. SNARK-и є бездоверчими. Семплювання доступності даних має тонку модель довіри 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.
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Що це? Як це працює?
PeerDAS є відносно простим впровадженням "1D sampling". В Ethereum кожен blob є 4096-м многочленом у полі простих чисел (prime field). Ми транслюємо частки многочлена, де кожна частка містить 16 значень оцінки з сусідніх 16 координат з загалом 8192 координат. Серед цих 8192 значень оцінки, будь-які 4096 з ( відповідно до поточних запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт слухав невелику кількість підмереж, де i-та підмережа транслює i-й зразок будь-якого блобу, та запитує у глобальних p2p-мережах рівноправних (, хто буде слухати різні підмережі ), щоб запитати інші блоби з необхідних підмереж. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до рівня рівноправних. Поточна пропозиція полягає в тому, щоб учасники підтвердження частки (staking) використовували SubnetDAS, тоді як інші вузли (, тобто клієнти ), використовували PeerDAS.
З теоретичної точки зору, ми можемо значно розширити масштаб "1D sampling": якщо ми збільшимо максимальну кількість blob до 256( з метою 128), тоді ми зможемо досягти цілі в 16 МБ, а у зразках доступності даних кожен вузол отримає 16 зразків * 128 blob * 512 байт на кожен blob за кожен зразок = 1 МБ пропускної здатності даних на кожен слот. Це лише з натяжкою вписується в наші межі терпимості: це здійсненно, але це означає, що клієнти з обмеженою пропускною здатністю не можуть виконувати зразки. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob і збільшуючи їхній розмір, але це підвищить витрати на відновлення.
Тому ми в кінцевому підсумку хочемо зробити ще один крок, провести 2D вибірку (2D sampling), цей метод не лише проводить випадкові вибірки всередині blob, але також виконує випадкові вибірки між blob. Використовуючи лінійні властивості KZG зобов'язань, ми розширюємо набір blob у блоці за допомогою нової групи віртуальних blob, які надлишково кодують ту ж інформацію.
Отже, зрештою, ми хочемо зробити ще один крок вперед, провести 2D- вибірку, яка здійснюється не лише всередині blob, а й випадковим чином між blob. Лінійні властивості KZG-обіцянок використовуються для розширення набору blob у блоці, що містить новий список віртуальних blob з надмірним кодуванням для однієї й тієї ж інформації.
Важливо зазначити, що розширення обіцянки не потребує наявності 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).
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
( Як взаємодіяти з іншими частинами дорожньої карти?
Якщо реалізувати стиснення даних, потреба в 2D DAS зменшиться, або принаймні відкладеться, якщо Plasma буде широко використовуватися, тоді потреба ще більше зменшиться. DAS також ставить виклики для протоколів і механізмів побудови розподілених блоків: хоча DAS теоретично є дружнім до розподіленого відновлення, на практиці це вимагає поєднання з пропозицією списку включення пакетів та механізмами вибору розгалуження навколо них.
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp###
Стиснення даних
( Яку проблему ми вирішуємо?
Кожна транзакція в Rollup займає значний обсяг даних на ланцюгу: передача ERC20 потребує близько 180 байтів. Навіть за ідеальної доступності даних це обмежує масштабованість Layer-протоколів. Кожен слот 16 МБ, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
Якщо ми зможемо вирішити не лише проблеми з чисельником, а й проблеми з знаменником, і зробити так, щоб кожна транзакція в Rollup займала менше байтів у ланцюгу, що тоді буде?
) Що це таке, як це працює?
На мою думку, найкраще пояснення - це це зображення дворічної давності:
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск]###https://img-cdn.gateio.im/webp-social/moments-a04daca8af5d6af3c06b77a97aae477d.webp###
У нульовій байтовій компресії, два байти замінюють кожну довгу послідовність нульових байтів, вказуючи, скільки нульових байтів є. Далі ми використали специфічні властивості транзакцій:
Агрегація підписів: ми перейшли від підпису ECDSA до підпису BLS. Особливістю підпису BLS є те, що кілька підписів можуть бути об'єднані в один єдиний підпис, який може підтвердити всі оригінальні.