Шлях мережі BNB до великих блоків

Дорога великих блоків у мережі BNB

Подібно до Solana, Heco та інших публічних ланцюгів, що підтримуються біржами, публічний ланцюг BNB Chain BNB Smart Chain (BSC) вже давно прагне до високої продуктивності. З моменту запуску в 2020 році BSC встановила ліміт потужності газу для кожного блоку на рівні 30 мільйонів, зі стабільним інтервалом між блоками в 3 секунди. З такими параметрами BSC досягла максимального TPS (TPS з різними транзакціями, змішаними разом) понад 100. У червні 2021 року ліміт блочного газу БСК було збільшено до 60 мільйонів. Однак у липні того ж року на BSC вибухнула мережева гра під назвою CryptoBlades, внаслідок чого щоденний обсяг транзакцій перевищив 8 мільйонів, а комісія стрімко зросла. Виявилося, що вузьке місце в ефективності BSC на той час було ще досить очевидним.

(Джерело: BscScan)

Щоб вирішити проблеми з продуктивністю мережі, BSC в черговий раз підвищила ліміт газу для кожного блоку, який тривалий час залишався стабільним на рівні 80-85 мільйонів кубометрів. У вересні 2022 року ліміт газу на блок BSC Chain було збільшено до 120 мільйонів, а до кінця року - до 140 мільйонів, що майже в п'ять разів більше, ніж у 2020 році. Раніше BSC планувала збільшити ліміт потужності блоків до 300 мільйонів, але, можливо, з огляду на велике навантаження на вузли валідатора, пропозиція щодо таких надвеликих блоків не була реалізована.

джерело: YCHARTS

Пізніше BNB Chain, схоже, більше зосередилася на модульному треку Layer2, ніж на розширенні Layer1. Цей намір ставав все більш очевидним від запуску zkBNB у другій половині минулого року до GreenField на початку цього року. Через великий інтерес до модульного блокчейну/Layer2, автор цієї статті використає opBNB як об'єкт дослідження, щоб виявити вузькі місця в продуктивності Rollup, порівнюючи його з Ethereum Layer2.

Посилення високої пропускної здатності BSC до шару DA opBNB

Як ми всі знаємо, Celestia узагальнила чотири ключові компоненти відповідно до робочого процесу модульного блокчейну: Рівень виконання: Виконує код контракту і завершує переходи між станами; Розрахунковий рівень: Обробляє докази шахрайства/докази дійсності і вирішує проблеми з'єднання між L2 і L1. Рівень консенсусу: Досягає консенсусу щодо впорядкування транзакцій. Рівень доступності даних (DA): Публікує дані, пов'язані з реєстром блокчейну, дозволяючи валідаторам завантажувати ці дані.

Серед них, рівень DA часто поєднується з рівнем консенсусу. Наприклад, дані DA Optimistic Rollup містять пакет послідовностей транзакцій у блоках L2. Коли повні вузли L2 отримують дані DA, вони знають порядок кожної транзакції в цьому пакеті. (З цієї причини спільнота Ефіріуму вважає, що шар DA і шар консенсусу пов'язані між собою при накладанні шарів Rollup).

Однак для Ethereum Layer2 пропускна здатність рівня DA (Ethereum) стала найбільшим вузьким місцем, що обмежує продуктивність Rollup. Це пов'язано з тим, що поточна пропускна здатність Ethereum занадто низька, що змушує Rollup максимально пригнічувати TPS, щоб запобігти нездатності основної мережі Ethereum обробляти дані, згенеровані L2. У той же час, низька пропускна здатність призводить до того, що велика кількість транзакційних інструкцій в мережі Ethereum знаходиться в стані очікування, що призводить до надзвичайно високого рівня плати за газ і подальшого збільшення витрат на публікацію даних для Layer2. Нарешті, багатьом мережам другого рівня доводиться впроваджувати рівні DA за межами Ethereum, наприклад, Celestia, а opBNB, який знаходиться близько до води, вирішив безпосередньо використовувати високу пропускну здатність BSC для впровадження DA, щоб вирішити проблему публікації даних. Для простоти розуміння представимо метод публікації даних DA для Rollup. На прикладі Arbitrum, ланцюжок Ethereum, керований EOA-адресою секвенсора Layer2, буде періодично відправляти транзакції на вказаний контракт. У вхідні параметри calldata цієї інструкції записуються упаковані дані транзакції, і відповідні події в ланцюжку запускаються, залишаючи постійний запис у журналах контрактів.

Таким чином, дані транзакцій Layer2 зберігаються в блоках Ethereum протягом тривалого часу. Люди, які здатні запускати L2-вузли, можуть завантажувати відповідні записи і аналізувати відповідні дані, але самі вузли Ethereum не виконують ці L2-транзакції. Легко помітити, що L2 лише зберігає дані про транзакції в блоках Ethereum, несучи витрати на зберігання, в той час як обчислювальні витрати на виконання транзакцій несуть самі вузли L2. Вищезгаданий метод реалізації DA Arbitrum, в той час як Optimism використовує EOA-адресу, контрольовану секвенсором, для передачі на іншу вказану EOA-адресу, несучи нову порцію даних транзакції Layer2 в додаткових даних. Що стосується opBNB, який використовує стек OP, то його метод публікації даних DA в основному такий самий, як і в Optimism.

Очевидно, що пропускна здатність шару DA обмежує розмір даних, які Rollup може опублікувати за одиницю часу, тим самим обмежуючи TPS. Враховуючи, що після EIP1559 обсяг газу в кожному блоці ETH стабілізується на рівні 30 мільйонів, а час роботи блоку після злиття становить близько 12 секунд, Ethereum може обробляти максимум 2,5 мільйона газу в секунду. Здебільшого газ, який споживається при розміщенні даних L2-транзакцій на байт в calldata, дорівнює 16, тому Ethereum може обробляти максимальний розмір calldata лише 150 КБ в секунду. Для порівняння, максимальний середній розмір даних викликів, що обробляється в BSC за секунду, становить близько 2910 КБ, що в 18,6 разів більше, ніж в Ethereum. Різниця між ними як шарами DA очевидна.

Підсумовуючи, Ethereum може передавати близько 150 КБ даних L2 транзакцій в секунду. Навіть після запуску EIP 4844 ця цифра не сильно зміниться, лише зменшиться плата за послуги прокурора. Отже, скільки даних про транзакції можна вмістити в 150 КБ за секунду? Тут потрібно пояснити ступінь стиснення даних при згортанні. У 2021 році Віталік був надто оптимістичним, підрахувавши, що Optimistic Rollup може стиснути розмір даних транзакції до 11% від початкового розміру. Наприклад, базовий переказ ETH, який спочатку займав 112 байт даних виклику, може бути стиснутий до 12 байт за допомогою Optimistic Rollup, перекази ERC-20 можуть бути стиснуті до 16 байт, а своп-транзакції на Uniswap можуть бути стиснуті до 14 байт. За його оцінкою, Ethereum може реєструвати близько 10 000 L2 транзакцій в секунду (з різними типами, змішаними разом). Однак, згідно з даними, оприлюдненими командою Optimism у 2022 році, фактичний рівень стиснення даних може досягти максимуму лише близько 37%, що в 3,5 рази нижче за оцінку Віталіка.

(Оцінка Віталіком ефекту масштабованості Rollup значно відрізняється від реальних умов)

(Реальні показники стиснення, що досягаються різними алгоритмами стиснення, розкриті Optimism)

Тому давайте наведемо розумну цифру: навіть якщо Ethereum досягне своєї межі пропускної здатності, максимальний TPS всіх оптимістичних роллапів разом узятих складе лише трохи більше 2000. Іншими словами, якби блоки Ethereum повністю використовувалися для передачі даних, опублікованих в оптимістичних роллапах, таких як Arbitrum, Optimism, Base і Boba, то сумарний TPS цих оптимістичних роллапів не досяг би і 3000, навіть при використанні найефективніших алгоритмів стиснення. Крім того, ми повинні враховувати, що після EIP1559 газова потужність кожного блоку в середньому становить лише 50% від максимального значення, тому наведене вище число має бути зменшене вдвічі. Після запуску EIP4844, незважаючи на те, що комісія за публікацію даних буде значно знижена, максимальний розмір блоку Ethereum не сильно зміниться (оскільки занадто великі зміни вплинуть на безпеку основного ланцюжка ETH), тому оціночне значення, наведене вище, не сильно зміниться.

За даними Arbiscan і Etherscan, пакет транзакцій на Arbitrum містить 1115 транзакцій, які споживають 1,81 млн газу на Ethereum. За екстраполяцією, якщо шар DA заповнений у кожному блоці, теоретична межа TPS Arbitrum становить приблизно 1500. Звичайно, враховуючи питання реорганізації блоку L1, Arbitrum не може публікувати пакети транзакцій на кожному блоці Ethereum, тому наведені вище цифри наразі є лише теоретичними. Крім того, з широким розповсюдженням смарт-гаманців, пов'язаних з EIP 4337, проблема DA стане ще більш гострою. Адже завдяки підтримці EIP 4337 можна налаштувати спосіб підтвердження особи користувача, наприклад, завантажити бінарні дані відбитків пальців або райдужної оболонки ока, що ще більше збільшить обсяг даних, які займають звичайні транзакції. Таким чином, низька пропускна здатність Ethereum є найбільшим вузьким місцем, що обмежує ефективність Rollup, і ця проблема може не бути вирішена належним чином протягом тривалого часу. З іншого боку, в ланцюжку BNB публічного ланцюжка BSC максимальний середній розмір даних викликів, що обробляються в секунду, становить приблизно 2910 КБ, що в 18,6 разів більше, ніж в Ethereum. Іншими словами, якщо рівень виконання може встигати, теоретична верхня межа TPS рівня 2 в екосистемі BNB Chain може досягати приблизно в 18 разів більше, ніж у ARB або OP. Ця цифра розрахована на основі поточної максимальної потужності блокчейну BNB Chain в 140 мільйонів блокчейнів з часом блокування 3 секунди.

Іншими словами, поточний сукупний ліміт TPS всіх роллапів в екосистемі BNB Chain в 18,6 разів перевищує ліміт Ethereum (навіть з урахуванням ZKRollup). З цієї точки зору легко зрозуміти, чому так багато проектів Layer2 використовують рівень DA під ланцюжком Ethereum для публікації даних, адже різниця досить очевидна. Однак питання не таке просте. Окрім проблеми пропускної здатності, стабільність самого рівня 1 також може впливати на рівень 2. Наприклад, більшість роллапів часто чекають кілька хвилин, перш ніж публікувати пакет транзакцій в Ethereum, враховуючи можливість реорганізації блоків першого рівня. Якщо блок рівня 1 буде реорганізовано, це вплине на блокчейн-журнал рівня 2. Тому секвенсор чекатиме на публікацію кількох нових блоків Layer1 після кожного випуску пакету транзакцій L2, що значно зменшує ймовірність відкату блоків, перш ніж публікувати наступний пакет транзакцій L2. Це фактично затримує час, коли блоки L2 остаточно підтверджуються, знижуючи швидкість підтвердження великих транзакцій (великі транзакції вимагають незворотних результатів для забезпечення безпеки). Таким чином, транзакції, які відбуваються в L2, стають незворотними тільки після публікації в блоках рівня DA і після того, як рівень DA згенерує певну кількість нових блоків. Це важлива причина, що обмежує продуктивність Rollup. Однак, швидкість генерації блоків в Ethereum низька - блок створюється за 12 секунд. Якщо припустити, що Rollup публікує пакет транзакцій L2 кожні 15 блоків, то інтервал між різними пакетами становитиме 3 хвилини, а після публікації кожного пакета транзакцій все одно потрібно чекати, поки буде згенеровано кілька блоків першого рівня, перш ніж вони стануть незворотними (за умови, що їх не буде оскаржено). Очевидно, що час від ініціювання до незворотності транзакцій на Layer2 Ethereum досить довгий, що призводить до низької швидкості розрахунків; в той час як ланцюжок BNB Chain витрачає лише 3 секунди на створення блоку, а блоки стають незворотними всього за 45 секунд (час, необхідний для створення 15 нових блоків). Виходячи з поточних параметрів, припускаючи однакову кількість транзакцій L2 і враховуючи незворотність блоків L1, кількість разів, коли opBNB може публікувати дані про транзакції в одиницю часу, може досягати 8,53 разів більше, ніж у Arbitrum (раз на 45 секунд для першого і раз на 6,4 хвилини для другого). Очевидно, що швидкість розрахунків великих транзакцій на opBNB набагато вища, ніж на Layer2 Ethereum. Крім того, максимальний розмір даних, що публікуються opBNB, може досягати в 4,66 рази більше, ніж у Layer2 Ethereum (ліміт блочного газу L1 першого становить 140 мільйонів, а другого - 30 мільйонів). 8.53 * 4.66 = 39.74. Це відображає розрив між opBNB та Arbitrum з точки зору обмеження TPS на практиці (наразі, з міркувань безпеки, ARB, здається, активно зменшує TPS, але теоретично, якщо TPS буде збільшено, він все одно буде в багато разів нижчим порівняно з opBNB).

(Секвенсор Arbitrum публікує партію транзакцій кожні 6-7 хвилин)

(секвенсор opBNB публікує партію транзакцій кожні 1-2 хвилини, найшвидша займає всього 45 секунд). Звичайно, є ще одне важливе питання, яке слід розглянути, - це плата за газ у шарі ДДЗ. Кожного разу, коли L2 публікує пакет транзакцій, існує фіксована вартість 21,000 gas, яка не пов'язана з розміром calldata, що є витратами. Якщо плата за газ для шару DA/L1 висока, що призводить до того, що фіксована вартість публікації пакету транзакцій на L2 залишається високою, секвенсор зменшить частоту публікації пакетів транзакцій. Крім того, при розгляді компонентів комісій L2, витрати на рівні виконання є дуже низькими, і їх часто можна ігнорувати, зосередившись лише на впливі витрат операторів на рівні виконання на комісію за транзакції. Підсумовуючи, можна сказати, що публікація даних про виклики однакового розміру споживає однакову кількість газу в Ethereum і BNB Chain, але ціна газу, що стягується в Ethereum, приблизно в 10 - десятки разів вища, ніж в BNB Chain. У перерахунку на комісію за транзакції L2, поточна комісія за транзакції користувачів на другому рівні Ethereum також приблизно в 10 - десятки разів вища, ніж на opBNB. В цілому, відмінності між opBNB і оптимістичним роллом на Ethereum досить очевидні.

(Транзакція зі споживанням 150 000 газу на Оптимізмі коштує $0,21)

(Транзакція зі споживанням 130 000 газу на opBNB коштує $0,004) Однак збільшення пропускної здатності рівня DA, хоча і може підвищити загальну пропускну здатність системи рівня 2, все ще має обмежений вплив на підвищення продуктивності окремих ролловерів. Це пов'язано з тим, що рівень виконання часто не обробляє транзакції достатньо швидко. Навіть якщо обмеження рівня DA можна проігнорувати, рівень виконання стає наступним вузьким місцем, що впливає на продуктивність Rollup. Якщо швидкість виконання на рівні виконання Layer2 є низькою, переповнення попиту на транзакції пошириться на інші Layer2, що в кінцевому підсумку призведе до фрагментації ліквідності. Тому покращення продуктивності рівня виконання також має вирішальне значення, слугуючи ще одним порогом над рівнем DA.

Прискорення opBNB на рівні виконання: Оптимізація кешу

Коли більшість людей обговорюють вузькі місця в продуктивності рівнів виконання блокчейну, вони неминуче згадують про два важливих вузьких місця: однопотокове послідовне виконання EVM, яке не може повністю використовувати центральний процесор, і неефективний пошук даних Merkle Patricia Trie, прийнятий в Ethereum. По суті, стратегії масштабування для рівня виконання зводяться до більш ефективного використання ресурсів центрального процесора і забезпечення якомога швидшого доступу до даних.

Рішення для оптимізації послідовного виконання EVM і Merkle Patricia Trie часто є складними і важкими для реалізації, в той час як більш економічно ефективні зусилля, як правило, зосереджуються на оптимізації кешу. Насправді, оптимізація кешу повертає нас до питань, які часто обговорюються в традиційному контексті Web2 і навіть у підручниках.

Як правило, швидкість, з якою процесор отримує дані з пам'яті, в сотні разів перевищує швидкість отримання даних з диска. Наприклад, вибірка даних з пам'яті може зайняти лише 0,1 секунди, в той час як вибірка з диска може зайняти 10 секунд. Тому зменшення накладних витрат, пов'язаних з читанням і записом на диск, тобто оптимізація кешу, стає важливим аспектом оптимізації рівня виконання блокчейну.

В Ethereum і більшості інших публічних ланцюжків база даних, яка записує стани адрес в ланцюжку, зберігається повністю на диску, в той час як так званий World State try є лише індексом цієї бази даних або каталогом, який використовується для пошуку даних. Кожного разу, коли EVM виконує контракт, йому потрібно отримати доступ до відповідних адресних станів. Отримання даних з дискової бази даних один за одним значно сповільнить виконання транзакцій. Тому створення кешу поза базою даних/диском є необхідним засобом прискорення.

opBNB безпосередньо використовує рішення для оптимізації кешу, що використовується BNB Chain. Згідно з інформацією, розкритою партнером opBNB, NodeReal, найперший ланцюжок BSC встановив три шари кешу між EVM і базою даних LevelDB, що зберігає стан. Концепція дизайну схожа на традиційні трирівневі кеші, де дані з більшою частотою доступу зберігаються в кеші. Це дозволяє процесору спочатку шукати потрібні дані в кеші. Якщо частота звернень до кешу достатньо висока, процесору не потрібно надмірно покладатися на диск для отримання даних, що призводить до значного покращення загальної швидкості виконання.

Пізніше NodeReal додав до цього функцію, яка використовує невикористані ядра процесора для попереднього зчитування даних, які EVM потрібно буде обробити в майбутньому, з бази даних і збереження їх в кеші. Ця функція називається "попереднє завантаження стану".

Принцип попереднього завантаження станів простий: процесори вузлів блокчейну багатоядерні, в той час як EVM працює в однопотоковому режимі послідовного виконання, використовуючи лише одне ядро процесора, залишаючи інші ядра процесора недозавантаженими. Щоб вирішити цю проблему, ядра процесора, які не використовуються EVM, можуть допомогти у виконанні завдань, передбачаючи дані, які знадобляться EVM з ще не обробленої послідовності транзакцій. Ці процесорні ядра за межами EVM будуть отримувати дані, які потрібні EVM, з бази даних, допомагаючи EVM зменшити накладні витрати на пошук даних і, таким чином, прискорити виконання.

Завдяки оптимізації кешу та відповідним апаратним конфігураціям, opBNB ефективно підштовхнув продуктивність рівня виконання свого вузла впритул до межі EVM, обробляючи до 100 мільйонів газів на секунду. Ці 100 мільйонів газів по суті є межею продуктивності немодифікованого EVM, що підтверджується даними експериментальних випробувань, проведених у відомій публічній мережі.

Коротко кажучи, opBNB може обробляти до 4761 простих переказів в секунду, 15003000 переказів токенів ERC20 в секунду і приблизно 5001000 операцій SWAP в секунду, виходячи з даних про транзакції, які спостерігаються на блокчейн-експлорерах. Порівнюючи поточні параметри, ліміт TPS opBNB в 40 разів перевищує ліміт Ethereum, більш ніж в 2 рази - ліміт BNB Chain і більш ніж в 6 разів - ліміт Optimism.

Звичайно, для рішень Ethereum Layer2, через суворі обмеження самого рівня DA, продуктивність значно знижується на основі продуктивності рівня виконання, при розгляді таких факторів, як час генерації блоків рівня DA і стабільність.

Для BNB Chain з високопродуктивним шаром DA, таким як opBNB, подвоєння ефекту масштабування є цінним, особливо враховуючи, що BNB Chain може містити кілька таких проектів масштабування. Можна передбачити, що BNB Chain вже включила рішення Layer2 під керівництвом opBNB в свої стратегічні плани і продовжить впроваджувати більш модульні блокчейн-проекти, включаючи впровадження ZK-доказів в opBNB і надання високодоступних шарів DA з додатковою інфраструктурою, такою як GreenField, в спробі конкурувати або співпрацювати з екосистемою Ethereum Layer2.

В епоху, коли багаторівневе масштабування стало трендом, чи кинуться інші публічні ланцюжки також підтримувати власні проекти Layer2, ще належить з'ясувати, але, безсумнівно, зміна парадигми в бік модульної блокчейн-інфраструктури вже відбувається.

Відмова від відповідальності:.

1. Ця стаття передрукована з[极客 Web3], всі авторські права належать оригінальному автору[Faust, 极客web3]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.