Дорожня карта Ethereum спочатку містила дві стратегії масштабування: шардінг та протоколи Layer2. Ці два підходи врешті-решт об'єдналися, сформувавши дорожню карту, зосереджену на Rollup, яка залишається актуальною стратегією масштабування Ethereum.
Дорожня карта, що зосереджується на Rollup, пропонує простий розподіл праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим основним шаром, тоді як L2 виконує завдання допомоги в розширенні екосистеми. Ця модель є дуже поширеною в суспільстві: існування судової системи (L1) покликане захищати контракти та права власності, тоді як підприємці (L2) будують на цій основі, сприяючи розвитку людства.
Цього року дорожня карта, орієнтована на Rollup, досягла важливих успіхів: з впровадженням EIP-4844 blobs значно збільшилася пропускна здатність даних Ethereum L1, кілька Ethereum Virtual Machine (EVM) Rollup перейшли до першої стадії. Кожен L2 існує як "шар" з власними внутрішніми правилами і логікою, різноманітність і різноманітність реалізації шарів тепер стали реальністю. Але цей шлях також стикається з деякими унікальними викликами. Тому наше нинішнє завдання - завершити дорожню карту, орієнтовану на Rollup, і вирішити ці проблеми, одночасно зберігаючи стійкість і децентралізацію, притаманні Ethereum L1.
У майбутньому Ethereum через L2 зможе досягти понад 100000 TPS;
Зберігати децентралізацію та стійкість L1;
Принаймні деякі L2 повністю успадкували основні властивості Ethereum ( довіри, відкритості, антикорупційності );
Ethereum має відчуватися як єдина екосистема, а не 34 різні блокчейни.
Зміст цього розділу
Парадокс трикутника масштабованості
Подальший прогрес у вибірці доступності даних
Стиснення даних
Узагальнений Плазма
Досвідчена L2 система доказів
Поліпшення міжопераційності між L2
Розширення виконання на L1
Парадокс трьох куточків масштабованості
Трикутний парадокс масштабованості стверджує, що між трьома характеристиками блокчейну існує суперечність: децентралізація (, низька вартість експлуатації вузлів ), масштабованість (, велика кількість оброблюваних транзакцій ) і безпека (, зловмисникам потрібно знищити велику частину вузлів у мережі, щоб змусити одну транзакцію зазнати невдачі ).
Варто зазначити, що трикутний парадокс не є теоремою і не має математичного доведення. Він надає евристичний математичний довід: якщо децентралізований дружній вузол може перевірити 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, що забезпечить для 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-й зразок будь-якого блоба, і запитує у глобальній p2p мережі однолітків (, хто прослуховуватиме різні підмережі ), щоб запитати необхідні йому блоби з інших підмереж. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до рівня однолітків. Поточна пропозиція полягає в тому, щоб учасники з підтвердженням прав власності використовували SubnetDAS, а інші вузли (, тобто клієнти ), використовували PeerDAS.
З теоретичної точки зору, ми можемо масштабувати «1D sampling» досить великою мірою: якщо ми збільшимо максимальну кількість blob до 256( з метою 128), тоді ми зможемо досягти цілі 16MB, а в зразках доступності даних кожен вузол має 16 зразків * 128 blob * кожен blob має по 512 байтів на зразок = 1 MB пропускної здатності даних на слот. Це лише ледь вписується в наші межі допустимого: це можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть здійснювати зразки. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob та збільшуючи їхній розмір, але це призведе до підвищення витрат на відновлення.
Отже, ми врешті-решт хочемо зробити наступний крок і провести 2D зразок (2D sampling), цей метод не тільки проводить випадкову вибірку всередині блоба, але й проводить випадкову вибірку між блобами. Використовуючи лінійні властивості KZG зобов'язань, розширити набір блобів у блоці за допомогою нової групи віртуальних блобів, які надмірно кодують однакову інформацію.
Отже, зрештою ми хочемо просунутися далі і провести 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 теоретично дружній до розподіленого відновлення, на практиці це вимагає поєднання з пропозицією списку включення пакетів та механізмом вибору розгалуження навколо нього.
Стиснення даних
) Яку проблему ми вирішуємо?
Кожна транзакція в 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.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
10 лайків
Нагородити
10
4
Поділіться
Прокоментувати
0/400
FloorSweeper
· 10год тому
ngmi якщо ти думаєш, що L1 це майбутнє... роллапи це те, де зараз справжній альфа.
Переглянути оригіналвідповісти на0
RugpullAlertOfficer
· 12год тому
Нехай Ethereum спочатку пробіжить кілька кілометрів.
Переглянути оригіналвідповісти на0
FlashLoanKing
· 12год тому
L2 знову на поверхні. Гарно спостерігайте за виставою.
Переглянути оригіналвідповісти на0
MEVEye
· 12год тому
Зрозумів roll, але я все ще хочу перекрити ланцюг.
Ethereum розширення нова глава: Глибина аналізу дорожньої карти The Surge
Можливе майбутнє Ethereum: сплеск
Дорожня карта Ethereum спочатку містила дві стратегії масштабування: шардінг та протоколи Layer2. Ці два підходи врешті-решт об'єдналися, сформувавши дорожню карту, зосереджену на Rollup, яка залишається актуальною стратегією масштабування Ethereum.
Дорожня карта, що зосереджується на Rollup, пропонує простий розподіл праці: Ethereum L1 зосереджується на тому, щоб стати потужним і децентралізованим основним шаром, тоді як L2 виконує завдання допомоги в розширенні екосистеми. Ця модель є дуже поширеною в суспільстві: існування судової системи (L1) покликане захищати контракти та права власності, тоді як підприємці (L2) будують на цій основі, сприяючи розвитку людства.
Цього року дорожня карта, орієнтована на Rollup, досягла важливих успіхів: з впровадженням EIP-4844 blobs значно збільшилася пропускна здатність даних Ethereum L1, кілька Ethereum Virtual Machine (EVM) Rollup перейшли до першої стадії. Кожен L2 існує як "шар" з власними внутрішніми правилами і логікою, різноманітність і різноманітність реалізації шарів тепер стали реальністю. Але цей шлях також стикається з деякими унікальними викликами. Тому наше нинішнє завдання - завершити дорожню карту, орієнтовану на Rollup, і вирішити ці проблеми, одночасно зберігаючи стійкість і децентралізацію, притаманні Ethereum L1.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
Підйом: ключова мета
У майбутньому 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 стала більш життєздатною для ширшого спектра сценаріїв використання, ніж коли-небудь.
Подальші досягнення в зразках доступності даних
Яку проблему ми вирішуємо?
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, що забезпечить для calldata 463-926 TPS.
Це суттєве покращення для Ethereum L1, але цього недостатньо. Ми хочемо більшої масштабованості. Наша середньострокова мета — 16 МБ на кожен слот, і якщо поєднати це з поліпшеннями стиснення даних Rollup, це забезпечить ~58000 TPS.
! Віталік Новини: Можливе майбутнє Ethereum, сплеск
Що це? Як це працює?
PeerDAS є відносно простим впровадженням "1D sampling". В Ethereum кожен blob є 4096-м поліномом на просторовому полі з 253 біт (prime field). Ми транслюємо частки полінома, де кожна частка містить 16 оцінок з 16 сусідніх координат з загальних 8192 координат. З цих 8192 оцінок будь-які 4096 з ( відповідно до поточних запропонованих параметрів: будь-які 64 з 128 можливих зразків ) можуть відновити blob.
Принцип роботи PeerDAS полягає в тому, щоб кожен клієнт прослуховував невелику кількість підмереж, де i-та підмережа транслює i-й зразок будь-якого блоба, і запитує у глобальній p2p мережі однолітків (, хто прослуховуватиме різні підмережі ), щоб запитати необхідні йому блоби з інших підмереж. Більш консервативна версія SubnetDAS використовує лише механізм підмереж, без додаткових запитів до рівня однолітків. Поточна пропозиція полягає в тому, щоб учасники з підтвердженням прав власності використовували SubnetDAS, а інші вузли (, тобто клієнти ), використовували PeerDAS.
З теоретичної точки зору, ми можемо масштабувати «1D sampling» досить великою мірою: якщо ми збільшимо максимальну кількість blob до 256( з метою 128), тоді ми зможемо досягти цілі 16MB, а в зразках доступності даних кожен вузол має 16 зразків * 128 blob * кожен blob має по 512 байтів на зразок = 1 MB пропускної здатності даних на слот. Це лише ледь вписується в наші межі допустимого: це можливо, але це означає, що клієнти з обмеженою пропускною здатністю не можуть здійснювати зразки. Ми можемо оптимізувати це певною мірою, зменшуючи кількість blob та збільшуючи їхній розмір, але це призведе до підвищення витрат на відновлення.
Отже, ми врешті-решт хочемо зробити наступний крок і провести 2D зразок (2D sampling), цей метод не тільки проводить випадкову вибірку всередині блоба, але й проводить випадкову вибірку між блобами. Використовуючи лінійні властивості KZG зобов'язань, розширити набір блобів у блоці за допомогою нової групи віртуальних блобів, які надмірно кодують однакову інформацію.
! Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск
Отже, зрештою ми хочемо просунутися далі і провести 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.
Я вважаю, що довгостроковий реальний шлях є:
Зверніть увагу, що навіть якщо ми вирішимо безпосередньо розширити виконання на рівні 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 займала на ланцюгу менше байтів, що тоді буде?
Що це таке, як це працює?
На мою думку, найкраще пояснення – це це зображення дворічної давності:
! [Віталік Нова стаття: Можливе майбутнє Ethereum, сплеск]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
У стисненні нульових байтів два байти замінюють кожен довгий нульовий байтовий ряд, вказуючи, скільки є нульових байтів. Далі ми використали специфічні властивості транзакцій:
Агрегація підписів: ми перейшли від підписів ECDSA до підписів BLS. Особливістю підписів BLS є те, що кілька підписів можуть бути об'єднані в один єдиний підпис, який може підтвердити дійсність усіх оригінальних підписів. На рівні L1, оскільки навіть при агрегації обчислювальні витрати на верифікацію залишаються високими, тому не розглядається використання підписів BLS.