Дорожня карта Ethereum спочатку містила дві стратегії масштабування: шардінг та протоколи другого рівня. З поглибленням досліджень ці два напрямки злилися воєдино, сформувавши дорожню карту, зосереджену на Rollup, що досі є поточною стратегією розширення Ethereum.
Дорожня карта, зосереджена на Rollup, пропонує простий розподіл праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим рівнем, тоді як L2 виконує завдання допомогти екосистемі розширитися. Ця модель поширена в суспільстві: існування судової системи (L1) не для досягнення надшвидкості та ефективності, а для захисту контрактів і прав власності, тоді як підприємці (L2) мають будувати на цій міцній базовій платформі, просуваючи розвиток людства.
Цього року дорожня карта, зосереджена на Rollup, досягла важливих результатів: з випуском блобів EIP-4844, пропускна здатність даних Ethereum L1 суттєво зросла, кілька Ethereum Virtual Machine (EVM) Rollup перейшли в першу стадію. Кожен L2 існує як "шар" з власними внутрішніми правилами та логікою, різноманітність і багатоаспектність реалізації шарів тепер стали реальністю. Але, як ми бачимо, цей шлях також стикається з деякими унікальними викликами. Тому наше теперішнє завдання полягає в завершенні дорожньої карти, зосередженої на Rollup, і вирішенні цих проблем, одночасно зберігаючи стійкість і децентралізацію, притаманні Ethereum L1.
Трикутник масштабованості – це ідея, висунута в 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 на кожному слоті, що триває 12 секунд, буде 3 блоби приблизно по 125 кБ, або доступна ширина смуги даних приблизно 375 кБ на кожен слот. Припустимо, що дані транзакцій публікуються безпосередньо в ланцюзі, тоді ERC20 переказ займає приблизно 180 байт, отже, максимальна TPS для Rollup в Ethereum становитиме: 375000 / 12 / 180 = 173,6 TPS.
Якщо ми додамо теоретичну максимальну величину calldata Ethereum (: кожен слот 30 мільйонів Gas / кожен байт 16 gas = кожен слот 1,875,000 байтів ), то це призведе до 607 TPS. Використовуючи PeerDAS, кількість blob може зрости до 8-16, що забезпечить 463-926 TPS для calldata.
Це значне підвищення для 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), то ми зможемо досягти цілі в 16MB, а у вибірці доступності даних кожен вузол отримує 16 зразків * 128 blob * по 512 байт на зразок для кожного blob = 1 MB пропускної спроможності даних на слот. Це лише ледве в межах нашого допустимого рівня: це можливо, але це означає, що клієнти з обмеженою пропускною спроможністю не можуть проводити вибірку. Ми можемо частково оптимізувати це, зменшивши кількість blob і збільшивши їхній розмір, але це призведе до підвищення вартості відновлення.
Отже, ми врешті-решт хочемо зробити крок далі, здійснити 2D вибірку (2D sampling), цей метод не лише проводить випадкову вибірку всередині blob, а також випадкову вибірку між blob. Використовуючи лінійні властивості KZG зобов'язань, розширити набір blob у блоці за допомогою набору нових віртуальних blob, ці віртуальні blob надмірно кодують ту ж інформацію.
Отже, в кінцевому підсумку ми хочемо зробити ще один крок вперед, провести 2D-означення, яке здійснюється не лише в межах блобу, але і між блобами. Лінійна властивість 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-71424e26868ad99f2adda7a27447820a.webp###
Стиснення даних
( Ми вирішуємо яку проблему?
Кожна транзакція в Rollup займає великий обсяг даних на ланцюзі: передача ERC20 потребує приблизно 180 байтів. Навіть якщо є ідеальна вибірка доступності даних, це обмежує масштабованість протоколу Layer. Кожен слот 16 МБ, отже, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
А що, якщо ми зможемо вирішити не лише проблеми з чисельником, але й проблеми з знаменником, щоб кожна транзакція в Rollup займала менше байтів в ланцюзі?
Що це таке і як це працює?
На мою думку, найкраще пояснення – це це зображення дворічної давності:
У компресії нульових байтів кожен довгий ряд нульових байтів замінюється на два байти, які вказують, скільки нульових байтів є. Далі ми використали специфічні властивості транзакцій:
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
11 лайків
Нагородити
11
3
Поділіться
Прокоментувати
0/400
RuntimeError
· 07-14 20:38
Гарно зроблено eth
Переглянути оригіналвідповісти на0
ChainMelonWatcher
· 07-14 20:34
Біжить досить надійно~
Переглянути оригіналвідповісти на0
DegenWhisperer
· 07-14 20:27
Тут грають з архітектурними шарами, досить добре пояснено.
Ethereum The Surge: від 100000 TPS до шляху розширення єдиного екосистеми
Майбутнє Ethereum: сплеск
Дорожня карта Ethereum спочатку містила дві стратегії масштабування: шардінг та протоколи другого рівня. З поглибленням досліджень ці два напрямки злилися воєдино, сформувавши дорожню карту, зосереджену на Rollup, що досі є поточною стратегією розширення Ethereum.
Дорожня карта, зосереджена на Rollup, пропонує простий розподіл праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим базовим рівнем, тоді як L2 виконує завдання допомогти екосистемі розширитися. Ця модель поширена в суспільстві: існування судової системи (L1) не для досягнення надшвидкості та ефективності, а для захисту контрактів і прав власності, тоді як підприємці (L2) мають будувати на цій міцній базовій платформі, просуваючи розвиток людства.
Цього року дорожня карта, зосереджена на Rollup, досягла важливих результатів: з випуском блобів EIP-4844, пропускна здатність даних Ethereum L1 суттєво зросла, кілька Ethereum Virtual Machine (EVM) Rollup перейшли в першу стадію. Кожен L2 існує як "шар" з власними внутрішніми правилами та логікою, різноманітність і багатоаспектність реалізації шарів тепер стали реальністю. Але, як ми бачимо, цей шлях також стикається з деякими унікальними викликами. Тому наше теперішнє завдання полягає в завершенні дорожньої карти, зосередженої на Rollup, і вирішенні цих проблем, одночасно зберігаючи стійкість і децентралізацію, притаманні Ethereum L1.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
The Surge: ключові цілі
У майбутньому 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% не може примусити мережу прийняти погані блоки.
Іншим способом вирішення трьох складнощів є архітектура Plasma, яка використовує хитру технологію для передачі відповідальності за моніторинг доступності даних користувачам у сумісний спосіб. Ще в 2017-2019 роках, коли ми мали лише засіб шахрайського доказу для розширення обчислювальної потужності, Plasma була дуже обмежена в забезпеченні безпеки виконання, але з поширенням SNARKs( нульових знань компактних ненав'язливих доказів), архітектура Plasma стала більш життєздатною для більш широких сценаріїв використання, ніж будь-коли раніше.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
Подальший прогрес у вибірці доступності даних
Яку проблему ми вирішуємо?
13 березня 2024 року, коли оновлення Dencun буде запущено, у блокчейні Ethereum на кожному слоті, що триває 12 секунд, буде 3 блоби приблизно по 125 кБ, або доступна ширина смуги даних приблизно 375 кБ на кожен слот. Припустимо, що дані транзакцій публікуються безпосередньо в ланцюзі, тоді ERC20 переказ займає приблизно 180 байт, отже, максимальна TPS для Rollup в Ethereum становитиме: 375000 / 12 / 180 = 173,6 TPS.
Якщо ми додамо теоретичну максимальну величину calldata Ethereum (: кожен слот 30 мільйонів Gas / кожен байт 16 gas = кожен слот 1,875,000 байтів ), то це призведе до 607 TPS. Використовуючи PeerDAS, кількість blob може зрости до 8-16, що забезпечить 463-926 TPS для calldata.
Це значне підвищення для 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), то ми зможемо досягти цілі в 16MB, а у вибірці доступності даних кожен вузол отримує 16 зразків * 128 blob * по 512 байт на зразок для кожного blob = 1 MB пропускної спроможності даних на слот. Це лише ледве в межах нашого допустимого рівня: це можливо, але це означає, що клієнти з обмеженою пропускною спроможністю не можуть проводити вибірку. Ми можемо частково оптимізувати це, зменшивши кількість blob і збільшивши їхній розмір, але це призведе до підвищення вартості відновлення.
Отже, ми врешті-решт хочемо зробити крок далі, здійснити 2D вибірку (2D sampling), цей метод не лише проводить випадкову вибірку всередині blob, а також випадкову вибірку між blob. Використовуючи лінійні властивості KZG зобов'язань, розширити набір blob у блоці за допомогою набору нових віртуальних blob, ці віртуальні blob надмірно кодують ту ж інформацію.
Отже, в кінцевому підсумку ми хочемо зробити ще один крок вперед, провести 2D-означення, яке здійснюється не лише в межах блобу, але і між блобами. Лінійна властивість 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-71424e26868ad99f2adda7a27447820a.webp###
Стиснення даних
( Ми вирішуємо яку проблему?
Кожна транзакція в Rollup займає великий обсяг даних на ланцюзі: передача ERC20 потребує приблизно 180 байтів. Навіть якщо є ідеальна вибірка доступності даних, це обмежує масштабованість протоколу Layer. Кожен слот 16 МБ, отже, ми отримуємо:
16000000 / 12 / 180 = 7407 TPS
А що, якщо ми зможемо вирішити не лише проблеми з чисельником, але й проблеми з знаменником, щоб кожна транзакція в Rollup займала менше байтів в ланцюзі?
Що це таке і як це працює?
На мою думку, найкраще пояснення – це це зображення дворічної давності:
У компресії нульових байтів кожен довгий ряд нульових байтів замінюється на два байти, які вказують, скільки нульових байтів є. Далі ми використали специфічні властивості транзакцій:
Підписна агрегація: Ми з