Новий текст Віталіка: можливе майбутнє 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.
The Surge: Ключова мета
У майбутньому Ethereum через L2 може досягти понад 100000 TPS;
Зберігати децентралізацію та надійність L1;
Принаймні деякі L2 повністю успадкували основні властивості Ethereum ( без довіри, відкритість, стійкість до цензури );
Ethereum повинен відчуватися як єдина екосистема, а не 34 різні блокчейни.
Трикутник масштабованості — це ідея, висунута в 2017 році, яка стверджує, що між трьома характеристиками блокчейну існує суперечність: децентралізація (, а саме: низька вартість роботи вузлів ), масштабованість (, що дозволяє обробляти велику кількість транзакцій ), і безпека (, що передбачає, що зловмиснику потрібно знищити значну частину вузлів у мережі, щоб зірвати одну транзакцію ).
Варто зазначити, що трикутний парадокс не є теоремою, публікації, що представляють трикутний парадокс, також не супроводжуються математичним доведенням. Він дійсно наводить евристичний математичний аргумент: якщо децентралізований дружній вузол (, наприклад, споживчий ноутбук ) може перевіряти N транзакцій за секунду, і у вас є ланцюг, який обробляє k*N транзакцій за секунду, тоді (i) кожна транзакція може бути видима лише 1/k вузлам, що означає, що зловмиснику потрібно знищити лише кілька вузлів, щоб провести шкідливу транзакцію, або (ii) ваші вузли стануть потужними, а ваш ланцюг не стане децентралізованим. Метою цієї статті ніколи не було довести, що руйнування трикутного парадоксу неможливе; навпаки, вона має на меті показати, що руйнування трійкового парадоксу є складним, і для цього потрібно вийти за рамки мисленнєвої структури, що передбачає цей аргумент.
Протягом багатьох років деякі високопродуктивні ланцюги стверджували, що вони вирішують трилему без суттєвих змін в архітектурі, зазвичай шляхом застосування програмних інженерних методів для оптимізації вузлів. Це завжди є оманливим, оскільки запуск вузлів на цих ланцюгах значно складніший, ніж на Ethereum. У цій статті буде розглянуто, чому це так, а також чому лише програмна інженерія L1-клієнта сама по собі не може масштабувати Ethereum?
Однак комбінація вибірки доступності даних та SNARKs дійсно вирішує трикутний парадокс: вона дозволяє клієнтам перевіряти, що певна кількість даних доступна, і що певна кількість обчислювальних кроків виконуються правильно, завантажуючи лише невелику кількість даних і виконуючи дуже мало обчислень. SNARKs не потребують довіри. Вибірка доступності даних має тонку модель довіри few-of-N, але зберігає основні характеристики ланцюга, що не підлягає масштабуванню, а саме, навіть атаки на рівні 51% не можуть змусити погані блоки бути прийнятими мережею.
Іншим способом вирішення трьох складнощів є архітектура Plasma, яка використовує хитрі технології для делегування відповідальності за доступність моніторингу даних користувачам у спосіб, сумісному з інтересами. Ще в 2017-2019 роках, коли у нас був лише засіб шахрайських доказів для розширення обчислювальних можливостей, Plasma була дуже обмежена в безпечному виконанні, але з поширенням SNARKs( нульових знань компактних неінтерактивних доказів) архітектура Plasma стала більш життєздатною для ширшого використання, ніж будь-коли.
Подальші досягнення в області вибірки доступності даних
Яку проблему ми вирішуємо?
13 березня 2024 року, коли оновлення Dencun стане доступним, блокчейн Ethereum буде мати 3 блоби приблизно по 125 кБ кожен на слот, що відбувається кожні 12 секунд, або приблизно 375 кБ доступної смуги пропускання на кожен слот. Припустимо, що дані транзакцій публікуються безпосередньо в ланцюзі, то переказ ERC20 становитиме близько 180 байт, тому максимальна TPS Rollup на Ethereum становитиме: 375000 / 12 / 180 = 173,6 TPS
Якщо ми додамо теоретичне максимальне значення calldata Ethereum (: кожен слот 30 мільйонів Gas / за байт 16 gas = кожен слот 1,875,000 байтів ), то це призведе до 607 TPS. Використовуючи PeerDAS, кількість блобів може зрости до 8-16, що забезпечить 463-926 TPS для calldata.
Це значне покращення для Ethereum L1, але цього недостатньо. Ми хочемо більше масштабованості. Наша середньострокова мета – 16 МБ на слот, якщо поєднати з покращеннями стиснення даних Rollup, це призведе до ~58000 TPS.
Що це? Як це працює?
PeerDAS є відносно простим впровадженням "1D sampling". В Ethereum кожен blob є 4096-м поліномом на полі простих чисел (. Ми транслюємо частини полінома, де кожна частина містить 16 оцінок з 16 сусідніх координат з загальних 8192 координат. Серед цих 8192 оцінок будь-які 4096 з ) можуть бути відновлені відповідно до наразі запропонованих параметрів: будь-які 64 з 128 можливих зразків (.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, де i-та підмережа транслює i-й зразок будь-якого blob, і запитує у глобальній p2p мережі щодо пари ), хто прослуховуватиме різні підмережі (, щоб запросити blob з інших підмереж, які йому потрібні. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до рівня пар. Поточна пропозиція полягає в тому, щоб дозволити вузлам, які беруть участь у доказі частки, використовувати SubnetDAS, тоді як інші вузли ), тобто клієнти (, використовують PeerDAS.
З теоретичної точки зору, ми можемо розширити масштаб "1D sampling" досить великим: якщо ми збільшимо максимальну кількість blob до 256) з метою 128(, тоді ми зможемо досягти цілі в 16 MB, а в зразках доступності даних кожен вузол має 16 зразків * 128 blob * по 512 байтів на кожен зразок blob = 1 MB пропускної спроможності даних на слот. Це лише ледве в межах нашої терпимості: це можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть здійснювати зразки. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob і збільшуючи їхній розмір, але це призведе до підвищення витрат на відтворення.
Тому врешті-решт ми хочемо зробити ще один крок вперед, провести 2D вибірку )2D sampling(, цей метод не тільки проводить випадкову вибірку всередині blob, а й між blob. Використовуючи лінійні властивості KZG зобов'язань, ми розширюємо набір blob у блоці за допомогою набору нових віртуальних blob, які надмірно кодують ту ж інформацію.
Отже, врешті-решт, ми хочемо зробити ще один крок вперед і здійснити 2D-відібрані зразки, які проводяться не лише всередині blob, а й між blob. Лінійні властивості KZG-зобов'язань використовуються для розширення набору blob у блоці, який містить новий віртуальний список blob, що містить надмірне кодування однієї й тієї ж інформації.
Важливо зазначити, що розширення обіцянки не вимагає наявності blob, тому це рішення в основному є дружнім до розподіленого побудови блоків. Фактичні вузли, що створюють блоки, повинні лише мати blob KZG обіцянку, і вони можуть покладатися на зразки доступності даних )DAS( для перевірки доступності блоків даних. Одновимірні зразки доступності даних )1DDAS( в основному також дружні до розподіленого побудови блоків.
) Що ще потрібно зробити? Які є компроміси?
Далі йдеться про завершення впровадження та запуску 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 займати менше байтів в мережі, що з цього вийде?
Що це таке, як це працює?
На мою думку, найкраще пояснення – це зображення дворічної давності:
У процесі стиснення нульових байтів ми замінюємо кожну довгу послідовність нульових байтів на два байти, які вказують, скільки нульових байтів є. Далі ми скористалися специфічними властивостями транзакції:
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
15 лайків
Нагородити
15
4
Поділіться
Прокоментувати
0/400
CryptoTarotReader
· 07-22 16:59
Ця хвиля L2 має до місяця!
Переглянути оригіналвідповісти на0
NightAirdropper
· 07-22 05:24
Ганді V Бог знову почав малювати BTC.
Переглянути оригіналвідповісти на0
LayerZeroHero
· 07-19 20:54
Дані не можуть втекти, стратегія розподілу праці неминуче призведе до rollup
Віталік розглядає майбутнє 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.
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 буде мати 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, кількість блобів може зрости до 8-16, що забезпечить 463-926 TPS для calldata.
Це значне покращення для Ethereum L1, але цього недостатньо. Ми хочемо більше масштабованості. Наша середньострокова мета – 16 МБ на слот, якщо поєднати з покращеннями стиснення даних Rollup, це призведе до ~58000 TPS.
Що це? Як це працює?
PeerDAS є відносно простим впровадженням "1D sampling". В Ethereum кожен blob є 4096-м поліномом на полі простих чисел (. Ми транслюємо частини полінома, де кожна частина містить 16 оцінок з 16 сусідніх координат з загальних 8192 координат. Серед цих 8192 оцінок будь-які 4096 з ) можуть бути відновлені відповідно до наразі запропонованих параметрів: будь-які 64 з 128 можливих зразків (.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, де i-та підмережа транслює i-й зразок будь-якого blob, і запитує у глобальній p2p мережі щодо пари ), хто прослуховуватиме різні підмережі (, щоб запросити blob з інших підмереж, які йому потрібні. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до рівня пар. Поточна пропозиція полягає в тому, щоб дозволити вузлам, які беруть участь у доказі частки, використовувати SubnetDAS, тоді як інші вузли ), тобто клієнти (, використовують PeerDAS.
З теоретичної точки зору, ми можемо розширити масштаб "1D sampling" досить великим: якщо ми збільшимо максимальну кількість blob до 256) з метою 128(, тоді ми зможемо досягти цілі в 16 MB, а в зразках доступності даних кожен вузол має 16 зразків * 128 blob * по 512 байтів на кожен зразок blob = 1 MB пропускної спроможності даних на слот. Це лише ледве в межах нашої терпимості: це можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть здійснювати зразки. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob і збільшуючи їхній розмір, але це призведе до підвищення витрат на відтворення.
Тому врешті-решт ми хочемо зробити ще один крок вперед, провести 2D вибірку )2D sampling(, цей метод не тільки проводить випадкову вибірку всередині blob, а й між blob. Використовуючи лінійні властивості KZG зобов'язань, ми розширюємо набір blob у блоці за допомогою набору нових віртуальних blob, які надмірно кодують ту ж інформацію.
Отже, врешті-решт, ми хочемо зробити ще один крок вперед і здійснити 2D-відібрані зразки, які проводяться не лише всередині blob, а й між blob. Лінійні властивості KZG-зобов'язань використовуються для розширення набору blob у блоці, який містить новий віртуальний список blob, що містить надмірне кодування однієї й тієї ж інформації.
Важливо зазначити, що розширення обіцянки не вимагає наявності blob, тому це рішення в основному є дружнім до розподіленого побудови блоків. Фактичні вузли, що створюють блоки, повинні лише мати blob KZG обіцянку, і вони можуть покладатися на зразки доступності даних )DAS( для перевірки доступності блоків даних. Одновимірні зразки доступності даних )1DDAS( в основному також дружні до розподіленого побудови блоків.
) Що ще потрібно зробити? Які є компроміси?
Далі йдеться про завершення впровадження та запуску 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, сплеск
У процесі стиснення нульових байтів ми замінюємо кожну довгу послідовність нульових байтів на два байти, які вказують, скільки нульових байтів є. Далі ми скористалися специфічними властивостями транзакції:
Підписна агрегація: ми з ECD