Оригінальне джерело: Gravity
Вступ
З моменту запуску Gravity Alpha Mainnet у серпні 2024 року ця мережа вже обробила понад 275 мільйонів транзакцій, з середньодобовим обсягом транзакцій до 2,6 мільйона та успішно реалізувала 30 мільйонів G витрат на транзакції. З публікацією Litepaper ми з нетерпінням чекаємо на майбутнє цього високопродуктивного EVM ланцюга. Ця стаття глибоко проаналізує Litepaper, розкриваючи, як Gravity створює видатну архітектуру високопродуктивного Layer-1 блокчейну для реальних застосувань.
Gravity - це високопродуктивний, сумісний з EVM Layer-1 блокчейн, створений Galxe, що виник у відповідь на потреби розвитку Galxe. Galxe, як найбільша у світі платформа для дистрибуції на базі блокчейну, з'єднує величезну багатоланцюгову екосистему, залучаючи понад 25 мільйонів користувачів. У процесі свого розвитку Galxe перетворилася на децентралізований супердодаток, інтегруючи інноваційні інструменти, такі як Quest, Passport, Score, Compass та Alva, водночас пропонуючи різноманітні послуги, такі як програми лояльності, NFT події, токенові винагороди, zk-ідентифікацію та міжланцюгові розумні заощадження. У процесі безперервного розвитку високий обсяг транзакцій Galxe став важливим фактором для розробки Gravity - система лояльності підтримує 51,2 транзакцій на секунду, а програми токенових винагород підтримують 32,1 транзакцій на секунду. Це спонукало нас перейти до EVM блокчейна під час децентралізації Galxe, водночас зберігаючи оптимальний досвід користувача.
З розвитком повної децентралізації Galxe очікується подальше зростання обсягу транзакцій. Очікується, що вимоги до пропускної здатності досягнуть 50 мільйонів gas на секунду, тоді як для задоволення більш широких екосистемних потреб (таких як міжланцюгові розрахунки, торгівля лояльністю та NFT-ринок) може знадобитися обробна потужність 500 мільйонів gas на секунду. Для цього Gravity має на меті підтримувати пропускну здатність 1 gigagas на секунду, щоб задовольнити вимоги до масштабування ресурсомістких додатків.
Серед існуючих рішень багато платформ забезпечують масштабованість через Ethereum, але виклики L2 Rollup неминуче призводять до затримок транзакцій, що є неприязно для додатків, які вимагають миттєвого підтвердження, таких як Galxe. Хоча деякі DApp намагаються компенсувати затримки через моделі довіри або зовнішній моніторинг, ці методи вводять додаткову складність і ризики, що явно не є ідеальним для критичних сценаріїв застосування.
На цьому фоні виникає Gravity. Gravity, ґрунтуючись на паралельному EVM, скорочує різницю в продуктивності між L2 та L1, розробляючи Grevm, нині найшвидшу відкриту паралельну EVM систему виконання. Крім того, Gravity модульно перепроєктував архітектуру Aptos, об'єднавши перевірені компоненти, такі як Quorum Store та консенсусний механізм AptosBFT. Завдяки зрілій архітектурі Aptos, Gravity уникла складності та потенційних ризиків, пов'язаних із розробкою з нуля. Врешті-решт, Gravity не лише створила високопродуктивний L1 блокчейн, який пропонує повний досвід, але й запустила перший SDK для конвеєра блокчейнів, значно спростивши процес взаємодії для розробників і користувачів.
Gravity забезпечує безпрецедентну масштабованість, децентралізацію та майже миттєву швидкість транзакцій. Його технологія поєднує переваги L1 та L2, забезпечуючи 10 000 транзакцій на секунду та підтвердження за частки секунди. Крім того, через інтеграцію протоколів повторного стейкінгу, таких як EigenLayer та Babylon, Gravity не лише забезпечує сильну безпеку на етапі запуску, але й знижує системні ризики, пов'язані з тривалими залежностями від єдиного активу.
У майбутньому Gravity просуватиметься відповідно до наступної дорожньої карти:
· Запуск фази Devnet 1, тестування реальної продуктивності;
· Запуск тестової мережі Longevity, перевірка довгострокової стабільності мережі;
· Перехід з Gravity Alpha Mainnet до повнофункціонального Gravity Mainnet, закладаючи основу для масштабного впровадження децентралізованих технологій.
Нижче наведено повний текст Gravity Litepaper.
Резюме
Gravity - це високопродуктивний, сумісний з EVM Layer-1 блокчейн, створений Galxe, спеціально розроблений для масштабних додатків та багатоланцюгової екосистеми. Його особливості включають пропускну здатність 1 gigagas на секунду, підтвердження транзакцій за частки секунди та механізм консенсусу PoS на основі повторного стейкінгу. Дизайн Gravity спирається на два основні відкриті компоненти: (1) Gravity SDK, який є механізмом консенсусу на основі повторного стейкінгу AptosBFT; (2) Gravity reth, виконавчий рівень, керований паралельним EVM Grevm (Gravity EVM). Ці інструменти забезпечують можливість створення альтернативних Layer-1 та ефективних Layer-2 для додатків Web3, особливо в контексті EVM ланцюгів. У цій статті детально розглядаються інженерні рішення та технічні інновації Gravity, демонструючи, як через архітектуру конвеєра, передові алгоритми консенсусу, паралельну технологію виконання та оптимізовані механізми зберігання (через вдосконалення reth та поліпшення консенсусного механізму Aptos) можна задовольнити вимоги до високої продуктивності.
Вступ
Розробка Gravity виникла з викликів, з якими Galxe зіткнулася під час роботи. Galxe - це провідний веб3 додаток, що пропонує користувачам програми лояльності, NFT події, винагороди токенами, нульове знання ідентифікації та міжланцюгові розумні заощадження. Завдяки стрімкому розвитку Galxe, його система лояльності обробляє в середньому 51,2 транзакції на секунду, а програми винагород токенами - 32,1 транзакції на секунду. У процесі поступової децентралізації Galxe перенесення цих випадків використання на EVM блокчейн, одночасно забезпечуючи плавний користувацький досвід, стало необхідним. Тому розробка високопродуктивного EVM блокчейну, здатного забезпечити (1) високу пропускну здатність транзакцій і (2) майже миттєве підтвердження транзакцій, стала критично важливою.
На цьому фоні вибір існуючих рішень Layer-2 або розробка нових Layer-1 є ключовим рішенням. Layer-1 реалізує остаточність за допомогою консенсусного алгоритму, тоді як Layer-2 вирішує цю проблему за допомогою протоколу Rollup. Існує компроміс: Layer-1 зазвичай жертвує частиною пропускної здатності через обмеження консенсусного алгоритму, але може забезпечити швидше остаточне підтвердження транзакцій. Наприклад, консенсусний алгоритм на основі AptosBFT може підтверджувати транзакції за частки секунди, тоді як оптимістичний Rollup може мати період викликів до семи днів. Хоча нульові знання можуть пришвидшити цей процес, остаточне підтвердження все ще може займати кілька годин. Ураховуючи потреби Gravity в остаточному підтвердженні за частки секунди (особливо для його протоколу загальної мети), ми обрали створення Layer-1.
Незважаючи на те, що Layer-2 має нативні переваги в комунікації з Ethereum, Layer-1, як Gravity, може забезпечити глибоку міжланцюгову взаємодію з Ethereum та іншими блокчейнами через протокол Gravity Intent і міжланцюгові мости. Цей дизайн не тільки забезпечує безперебійну співпрацю з Ethereum, а й покращує зв'язність усієї екосистеми Web3.
Крім того, протокол повторного стейкінгу (restaking) значно знижує складність створення PoS Layer-1 блокчейну. Gravity за допомогою протоколів, таких як EigenLayer та Babylon, інтегрує стейкінгові активи Ethereum та Bitcoin та їх широку мережу валідаторів. Це забезпечує економічну підтримку для PoS консенсусу, дозволяючи Gravity досягти рівня децентралізації та безпеки, що відповідає Ethereum.
Отже, Gravity створено як високопродуктивний, EVM-сумісний Layer-1 блокчейн для задоволення вимог сучасних веб3 додатків до масштабованості та продуктивності. Хоча його початковий намір полягав у обслуговуванні Galxe, гнучка архітектура, яку пропонують Gravity SDK та Grevm (Gravity EVM), підходить для створення будь-якого Layer-1 та ефективного Layer-2, функціонально подібного до Tendermint/Cosmos SDK.
Нам потрібна пропускна здатність 1 gigagas/s
Для блокчейну пропускна здатність є найважливішим показником продуктивності, зазвичай вимірюється кількістю транзакцій на секунду (TPS) або споживанням газу на секунду (gas/s). Наприклад, система лояльності Galxe вимагає щонайменше 4 мільйонів gas/s для стабільної роботи. Ця цифра базується на тому, що кожна транзакція з лояльності в середньому споживає 80 000 gas, а також обробляє близько 51,2 транзакції на секунду.
Цей прогноз отримав підтвердження з практичних даних Gravity Alpha Mainnet. Як Layer 2 мережа в нашому тестуванні, транзакції з лояльності Gravity Alpha Mainnet продемонстрували стабільну пропускну здатність 4 мільйони gas/s, підтверджуючи точність наведених оцінок.
Хоча високі витрати на операції в ланцюзі можуть призвести до незначного зниження попиту, тренд розширення Galxe вказує на те, що в години пік попит може зростати до двох або трьох разів від поточного рівня. Крім того, з появою інших сценаріїв використання, таких як NFT, токенові винагороди та підтримка повного ланцюга з нульовими знаннями в майбутньому, якщо Galxe повністю перейти на ланцюг, очікується, що вимоги до пропускної здатності досягнуть 50 мільйонів gas/s. Припустимо, що використання gas на ланцюзі Gravity слідує розподілу Парето (схоже на те, як Uniswap постійно споживає 10% gas Ethereum), щоб задовольнити більш широкі екосистемні потреби, такі як міжланцюгові розрахунки, торгівля лояльністю та NFT-ринок, в ідеалі слід підтримувати пропускну здатність 500 мільйонів gas/s. Тому, щоб задовольнити ці потенційні потреби, блокчейн повинен мати обробну потужність 1 gigagas на секунду, щоб забезпечити його здатність адаптуватися до масштабування ресурсомістких застосунків.
Щоб досягти такої високої пропускної здатності, ключовим є впровадження паралельного EVM. Ми розробили Grevm, нині найшвидшу відкриту паралельну EVM систему виконання, конкретна продуктивність якої буде описана в подальших розділах.
Час підтвердження за частки секунди
Окрім пропускної здатності, швидкість підтвердження транзакцій є критично важливою для досвіду користувача. Сучасні користувачі звикли до майже миттєвих відповідей, що залишає викликом для блокчейнів. Наприклад, Galxe має певні вимоги до низької затримки, як це буває у повністю децентралізованих іграх на базі блокчейна. Наразі час підтвердження транзакцій у більшості EVM блокчейнів варіюється від кількох секунд до кількох днів, що не відповідає цим вимогам. Ми обрали алгоритм консенсусу AptosBFT для досягнення підтвердження за частки секунди.
Хоча L2 Rollup теоретично може підвищити пропускну здатність, їх періоди виклику призводять до затримок транзакцій, що є неприпустимим для додатків, які вимагають миттєвого підтвердження (такі як Galxe). Хоча деякі DApp намагаються оптимізувати це через моделі довіри або зовнішній моніторинг, це вводить додаткову складність і ризики, що не є ідеальним для критичних застосувань. Gravity SDK скорочує різницю в продуктивності між L2 та L1 шляхом проектування п'ятиетапного конвеєра, що паралелізує процеси консенсусу та виконання (конкретний дизайн буде розглянуто далі).
Безпека PoS на основі повторного стейкінгу
Gravity SDK забезпечує безпечне розширення Ethereum, не обмежуючись L2 Rollup, натомість обираючи архітектуру L1 на основі повторного стейкінгу, щоб збалансувати продуктивність, міжланцюгову взаємодію та безпеку. Основні модулі інтегрують протоколи повторного стейкінгу, такі як EigenLayer та Babylon, що забезпечує економічну підтримку довіри для побудови стійкого консенсусу на основі доказу частки.
Завдяки 45 мільярдам доларів стейкінгових активів Ethereum та 850 000 валідаторів, а також 600 мільярдам доларів активів Bitcoin через Babylon, Gravity може з самого початку закласти міцний фундамент безпеки, уникаючи поширених проблем запуску та ризиків безпеки нових блокчейнів, одночасно зменшуючи системні ризики, пов'язані з тривалою залежністю від єдиного активу.
Архітектура Gravity Chain
Gravity Chain містить два основні компоненти: Gravity SDK та Gravity reth. Gravity SDK - це вдосконалена блокчейн-основа, розроблена на базі Aptos, який є найсучаснішим PoS блокчейном, заснованим на родині алгоритмів консенсусу HotStuff, чия архітектура конвеєра значно підвищує пропускну здатність та ефективність ресурсів. Gravity reth - це виконавчий рівень на основі reth, який працює у формі реактора потоків блоків (BSR), призначеного для отримання запропонованих блоків з консенсусного рівня. Оптимізуючи reth, Gravity reth реалізує паралельне виконання, асинхронні обчислення стану та підвищення ефективності зберігання. Ці два компоненти тісно пов'язані через інтерфейс консенсусного механізму Gravity (GCEI) та адаптер reth, а прогрес кожного етапу динамічно управляється контролером конвеєра.
Цей дизайн відокремлює виконання блоків від консенсусу блоку, дозволяючи виконавчому рівню бути споживачем запропонованих блоків. Наша оптимізація reth робить його ідеально придатним для процесу пропозиції блоків, керованого реактором потоків блоків (BSR).
Процес транзакцій у Gravity Chain виглядає наступним чином:
1. Транзакція подається через інтерфейс Gravity reth JSON RPC, який повністю сумісний з Ethereum.
2. Потім транзакція входить до пулу пам'яті Gravity SDK і поширюється в мережі, валідатори обробляють транзакції пакетами та генерують сертифікати Quorum Store (QS).
3. Кожен раунд лідера пропонує блок, що містить метадані блоку та впорядковані транзакції, обрані з пулу пам'яті та QS.
4. Після того, як пропозиція позначена як впорядкована, вона переходить до виконавчого рівня.
5. Виконавчий рівень Grevm обробляє транзакції паралельно, генеруючи результати виконання та передаючи новий стан модулю управління станом.
6. Модуль стану обчислює корінь стану та передає його до консенсусного механізму для досягнення консенсусу щодо кореня стану.
7. Після остаточного підтвердження кореня стану, модуль зберігання персистує корінь стану та дані блоку.
У наступних розділах буде детально розглянуто кожен компонент.
Gravity SDK: інноваційна практика відкритого коду для блокчейнів конвеєра
Gravity SDK - це модульна відкрита блокчейн основа, розроблена на основі готового до виробництва блокчейну Aptos. Його мета - модульно перепроектувати архітектуру Aptos, спираючись на перевірені компоненти, такі як Quorum Store та консенсусний механізм AptosBFT, щоб створити перший SDK для блокчейнів конвеєра.
Причини вибору Aptos як основи Gravity SDK включають:
· Топова технологічна архітектура: Aptos є просунутим PoS блокчейном на основі консенсусу родини HotStuff.
· Максимальна продуктивність: Aptos забезпечує пропускну здатність 160 000 транзакцій на секунду, а час остаточного підтвердження становить менше 1 секунди.
· Надійність у реальних умовах: Aptos було перевірено в умовах виробництва, продемонструвавши видатну стабільність та ефективність.
· Уникнення повторного винаходу колеса: використання зрілої архітектури Aptos дозволяє уникнути складності та потенційних ризиків, пов'язаних із розробкою з нуля, тоді як інші спроби перевершити Aptos, як правило, виявляються теоретично недостатніми.
· Синергія: з розвитком Aptos Gravity SDK може безшовно інтегрувати свої нові можливості, такі як API випадкових чисел, одночасно через модульну архітектуру та інноваційні механізми безпеки підживлювати Aptos.
Блокчейн на основі Gravity SDK підключається до конвеєрного механізму консенсусу через інтерфейс консенсусного механізму Gravity (GCEI). Хоча GCEI сумісний з кількома виконавчими рівнями, Gravity SDK наразі в основному підтримує Gravity reth. Деталі щодо GCEI будуть розглянуті в подальших розділах.
Інтерфейс Gravity Consensus Engine (GCEI)
Протокол GCEI (Gravity Consensus Execution Interface) є комунікаційним мостом між консенсусним та виконавчим рівнями. Він регламентує взаємодію між двома шарами, забезпечуючи синхронізацію процесів консенсусу та виконання за допомогою контролера конвеєра.
Основна різниця між традиційним блокчейн SDK та Gravity SDK полягає в його конвеєрному механізмі консенсусу. Виконавчий рівень повинен бути реалізований як реактор потоків блоків (Block Stream Reactor), що означає, що він повинен мати можливість безперервно споживати запропоновані потоки блоків, а угода про стан повинна асинхронно обчислюватися з виконанням транзакцій. Крім того, виконавчий рівень повинен мати можливість надавати сигнал зворотного тиску консенсусному рівню, щоб динамічно регулювати темп пропозицій блоків.
Крім того, через конвеєр Gravity SDK виконавчий рівень повинен мати можливість обробляти непрохідні транзакції в запропонованих блоках, оскільки пул пам'яті не може строго перевірити жодну транзакцію через відсутність доступу до останнього світового стану: виконання може ще не бути завершено. Водночас результати виконання не повинні блокувати створення наступних блоків, оскільки після паралелізації консенсусу блоку і консенсусу стану в Gravity SDK виконавчий рівень перетворюється на реактор потоків запропонованих блоків, що дозволяє вільно повертати результати виконання на наступних етапах.
Протокол GCEI визначає дві групи API:
· API консенсусного рівня: ці API реалізовано в Gravity SDK для того, щоб виконавчий рівень реагував на пропозиції консенсусного механізму та надсилав угоду про стан.
· API виконавчого рівня: ці API повинні бути реалізовані виконавчим рівнем. Консенсусний механізм використовуватиме ці API для перевірки транзакцій перед їх внесенням до блоку, обробки запропонованих блоків та повідомлення виконавчому рівню про остаточну угоду щодо стану.
З точки зору життєвого циклу транзакцій, протокол GCEI визначає наступне:
1. check_txn (API виконавчого рівня)
· Вхідні дані: отримати транзакцію (GTxn) як вхідні дані.
· Вихід: повертає адресу відправника транзакції, nonce та обмеження gas.
Призначення: цей метод використовується консенсусним механізмом для проведення зусиль з перевірки транзакцій перед їх внесенням до блоку. Цей метод може викликатися кілька разів для однієї й тієї ж транзакції, наприклад, коли транзакція потрапляє до пулу пам'яті, перед тим, як її запропонують до блоку, та коли угода про стан остаточно затверджена.
2. submit_txn (API консенсусного рівня)
Вхідні дані: отримати транзакцію (GTxn) від виконавчого рівня.
Вихід: повертає Result<(), що вказує, чи була транзакція успішно додана до пулу пам'яті.
Призначення: виконавчий рівень може використовувати цей метод для подання транзакцій до пулу пам'яті. Консенсусний механізм потім поширює цю транзакцію через мережу і формує Quorum Store після отримання пакету транзакцій.
3. recv_ordered_block (API виконавчого рівня)
Вхідні дані: отримати ordered_block (типу BlockBatch), який містить впорядковані транзакції та метадані блоку.
Вихід: повертає Result<(), що вказує, чи був блок успішно отриманий і прийнятий виконавчим рівнем.
Призначення: як тільки консенсусний механізм пропонує блок, його відправляють до виконавчого рівня для виконання транзакцій. Цей метод дозволяє виконавчому рівню отримувати та обробляти запропоновані блоки.
4. update_state_commitment (API консенсусного рівня)
Вхідні дані: угода про стан для певного номера блоку (StateCommitment).
Вихід: повертає Result<(), що вказує, чи була угода успішно прийнята локальним консенсусним механізмом.
Призначення: після розрахунку угоди про стан виконавчий рівень надсилає її до консенсусного рівня для остаточного затвердження, тобто для досягнення легкого консенсусу 2f+1 з іншими валідаторами. Якщо консенсус угоди про стан занадто сильно відстає від прогресу запропонованого блоку, контролер конвеєра налаштує темп пропозицій блоків.
5. commit_block_hash (API виконавчого рівня)
Вхідні дані: отримати вектор block_ids, що вказує на блоки, які потрібно подати.
Вихід: повертає Result<(), що вказує на успішність операції.
Призначення: коли угода про стан остаточно затверджується, консенсусний рівень сповіщає виконавчий рівень про те, щоб подати хеш блоку до зберігання блокчейну.
Конвеєр блокчейну
Gravity SDK використовує п'ятиетапну архітектуру конвеєра для максимізації використання апаратних ресурсів, що забезпечує вищу пропускну здатність та нижчу затримку. Конвеєр виконує завдання, чергуючи їх між різними блоками, а менеджер конвеєра використовує механізм зворотного зв'язку, щоб забезпечити стабільний рух блокчейну вперед. Перші три етапи належать до консенсусного рівня, а два останні - до виконавчого рівня.
Кожен етап пояснюється нижче:
· Етап 1: Поширення транзакцій: на цьому етапі транзакції ефективно розповсюджуються між валідаторами, забезпечуючи своєчасне та надійне включення транзакцій під час побудови блоку. У дизайні роз'єднується поширення транзакцій і механізм консенсусу, дотримуючись принципів Narwhal & Tusk та Aptos, що дозволяє валідаторам безперервно ділитися пакетами транзакцій, використовуючи всі ресурси мережі для паралельної роботи. Коли пакет транзакцій отримує вагове підписання 2f+1 (формуючи PoAv, тобто доказ доступності), гарантується, що цей пакет зберігається принаймні f+1 чесними валідаторами, що забезпечує доступність цих транзакцій для виконання всім чесним валідаторам.
· Етап 2: Сортування метаданих блоку: на цьому етапі в мережі встановлюється послідовність транзакцій та метаданих блоку, що є єдиною та визнаною. Консенсусний механізм (AptosBFT) дотримується дволанцюгового правила (2-chain rule), щоб забезпечити блоки з байдужим захистом. Блоки потім перейдуть до етапу виконання, готові до паралельної обробки.
· Етап 3 (BSR): Паралельне виконання транзакцій: цей етап є частиною виконавчого рівня, на цьому етапі транзакції виконуються паралельно. Результати виконання будуть передані на етап угоди про стан.
· Етап 4: Угода про стан: на цьому етапі завершується зміна стану, викликана виконанням транзакцій, і готується до остаточного затвердження блоку. Подання стану та виконання транзакцій асинхронно обчислюються, забезпечуючи, щоб виконання наступного блоку не заважало поточному блоку.
· Етап 5: Персистенція стану: на цьому етапі зміни стану, що були затверджені, персистуються до блоку зберігання. Остаточний корінь стану та відповідні дані зберігаються в Gravity Store, який має високооптимізований механізм зберігання, розроблений для швидкого доступу та надійності. Одночасно повідомляючи пул пам'яті та Quorum Store про очищення транзакцій, які більше не можуть бути включені.
Модулі стейкінгу та повторного стейкінгу
Створення безпечного блокчейну Layer 1 на базі доказу частки (PoS) є складним завданням, особливо в умовах, коли стейкінг здійснюється лише за допомогою специфічних токенів. На ранніх етапах цей підхід може стикатися з проблемами економічної безпеки, такими як коливання вартості токенів або обмежена участь валідаторів. Щоб вирішити цю проблему, Gravity SDK пропонує гнучкий модуль стейкінгу та повторного стейкінгу, призначений для підвищення безпеки мережі через локальні та зовнішні механізми стейкінгу.
Однією з ключових стратегій Gravity SDK є впровадження протоколів повторного стейкінгу, таких як EigenLayer та Babylon. Ці протоколи дозволяють валідаторам повторно ставити активи з інших зрілих мереж (таких як Ethereum та Bitcoin), використовуючи їх існуючі механізми безпеки. Дозволяючи валідаторам ставити активи з цих ланцюгів, Gravity SDK може підвищити економічну безпеку мережі, не покладаючись повністю на локальні токени. Цей підхід не тільки зміцнює стійкість ланцюга, але й сприяє різноманітності екосистеми валідаторів. Дизайн модуля стейкінгу базується на модульності, а його компоненти повторного стейкінгу мають високу гнучкість, що дозволяє легко адаптувати нові протоколи повторного стейкінгу в міру еволюції екосистеми блокчейнів.
Цей модуль підтримує не лише активи повторного стейкінгу, а й дозволяє ставити кастомні токени ERC20 на підтримуваних ланцюгах, наприклад, G Token на Ethereum. Валідатори можуть брати участь у консенсусі, ставлячи ці дозволені токени, що сприяє безпеці мережі. Голосування валідаторів розраховується на основі їхньої загальної вартості стейкінгу, включаючи кастомні токени та активи з протоколу повторного стейкінгу. Це розрахунок здійснюється відповідно до специфікацій ланцюга, що забезпечує гнучкість налаштування правил стейкінгу та повторного стейкінгу для кожного ланцюга.
Менеджер Epoch у консенсусному механізмі безпосередньо співпрацює з модулем стейкінгу для розрахунку ваги набору валідаторів наступного раунду. Він забезпечує точність процесу консенсусу, точно відображаючи останні зміни в стейкінгу, отримуючи значення стейкінгу від виконавчого рівня. У цій архітектурі міжланцюгові активи (наприклад, активи стейкінгу з Ethereum) повинні спочатку бути перенесені до виконавчого рівня, перш ніж їх можна буде використовувати для розрахунку загальної вартості стейкінгу валідаторів. Реалізація механізму перенесення є відповідальністю виконавчого рівня, що дозволяє більш гнучко обробляти міжланцюгову комунікацію. Можливі рішення включають мости PoS, нульові знання про стан ланцюга та вбудовану самостартуючу міжланцюгову передачу повідомлень.
Більше технічних деталей, дизайну API та повного опису механізмів стейкінгу та повторного стейкінгу буде представлено в подальших документах.
Gravity Reth: виконавчий рівень EVM реактора потоків блоків
Інтеграція виконавчого рівня Ethereum Virtual Machine (EVM) в архітектуру Gravity SDK принесли унікальні виклики, особливо при повному використанні можливостей його конвеєрного механізму консенсусу. Щоб досягти безшовної інтеграції та максимально реалізувати потенціал цієї архітектури, нам потрібно було внести кілька ключових оптимізацій у відкритий Ethereum-клієнт reth. Ці оптимізації кардинально перетворили reth на Gravity reth, оптимізований виконавчий рівень EVM для конвеєрного механізму консенсусу.
Традиційні архітектури блокчейнів обробляють блоки послідовно, гарантуючи, що кожен блок повністю перевірений і виконаний перед тим, як запропонувати наступний блок. Однак Gravity SDK використовує механізм консенсусу конвеєра, розділяючи етапи обробки блоків для підвищення продуктивності. Ця зміна парадигми вводить складність:
Неочікувані транзакції: у ланцюзі конвеєра, оскільки виконання попереднього блоку ще не завершено, пул пам'яті не може отримати доступ до останнього світового стану. Таким чином, транзакції, що містяться в запропонованому блоці, можуть не виконуватися в момент пропозиції, оскільки їхня дійсність не може бути строго перевірена без останнього стану.
Неперешкоджувані результати виконання: щоб запобігти зупинці конвеєра, результати виконання не повинні блокувати створення наступних блоків. Виконавчий рівень повинен мати можливість асинхронно обробляти запропоновані блоки та повертати результати виконання на пізніших етапах без перешкоджання процесу консенсусу. Для EVM це означає, що потрібно переосмислити blockhash, усунувши залежність від поля stateRoot у заголовку блоку.
Щоб вирішити ці проблеми, ми впровадили чотири ключових оптимізації:
· Реактор потоків блоків (Block Stream Reactor, BSR): BSR призначений для налаштування reth до процесу пропозиції блоків Gravity SDK. Це дозволяє виконавчому рівню безперервно споживати пропоновані потоки блоків, виступаючи як реактор для асинхронної обробки блоків. BSR встановлює динамічний зворотний зв'язок з консенсусним механізмом, поєднуючи відповідні сигнали зворотного тиску. Ці сигнали в реальному часі налаштовують темп пропозицій блоків та подання стану на основі продуктивності та затримки виконавчого рівня. Якщо через складні транзакції або обмеження ресурсів виконавчий рівень відстає, механізм зворотного тиску знижує темпи пропозицій блоків, щоб забезпечити стабільність системи.
· Роз'єднання подання стану та виконання транзакцій: друга оптимізація стосується відокремлення обчислення подання стану від виконання транзакцій. За допомогою роз'єднання цих процесів ми реалізуємо асинхронізацію обчислення подання стану, що дозволяє виконанню наступного блоку не чекати на завершення подання стану поточного блоку. Ми переосмислили blockhash, усунувши залежність від поля stateRoot у заголовку блоку, що гарантує, що обчислення кореня стану не перешкоджає створенню наступних блоків.
· Оптимізація рівня зберігання: в архітектурі конвеєра ефективне кешування та збереження мультиверсійних значень стану та стану є критично важливими. Третя оптимізація зосереджується на поліпшенні рівня зберігання, щоб задовольнити ці потреби, не вводячи вузькі місця. Оптимізуючи механізм зберігання, ми забезпечуємо швидке записування стану даних і високу паралельність. Це включає створення мультиверсійного механізму зберігання та підтримку асинхронного I/O від бази даних до API зберігання.
· Паралельний EVM: остання оптимізація стосується паралелізації виконання транзакцій у EVM. Ми розробили Grevm, паралельний EVM runtime, який значно прискорює обробку транзакцій через паралельне виконання. Grevm використовує дані з моделювання транзакцій для оптимізації паралельного виконання, зменшуючи повторне виконання транзакцій і підвищуючи пропускну здатність.
Grevm (Gravity EVM) - паралельне виконання EVM
Grevm - це відкритий проект, розміщений на GitHub (якщо ще не відкритий, у майбутньому буде відкритий). Будь ласка, зверніться до його README для отримання додаткової інформації.
Grevm (Gravity EVM) є відкритим паралельним EVM runtime, заснованим на revm. Алгоритм Grevm надихнувся BlockSTM і був вдосконалений шляхом впровадження графа залежностей даних транзакцій, отриманих з моделювання. Цей механізм робить планування паралельного виконання більш ефективним, максимально зменшуючи повторне виконання транзакцій.
У наших бенчмарках Grevm є найшвидшою відкритою паралельною реалізацією EVM. Для неперекриваючих транзакцій Grevm працює в 4,13 рази швидше, досягаючи швидкості 26,50 gigagas/s. Якщо змоделювати затримку I/O в реальному світі в 100 μs, його швидкість перевищує послідовне виконання в 50,84 разів, а пропускна здатність складає 6,80 gigagas/s. Цей стрибок продуктивності зумовлений інтеграцією паралельного виконання та асинхронних операцій вводу/виводу - паралелізація дозволяє ефективно перекривати операції вводу/виводу, що ще більше прискорює процес.
Основна ідея Grevm полягає в тому, щоб використовувати залежності даних між транзакціями для оптимізації паралельного виконання через спекулятивні набори читання/запису транзакцій. Хоча всі підказки не є абсолютно точними, ці спекулятивні підказки зазвичай є достатньо практичними. Наприклад, в Ethereum, згідно з історичним використанням gas, приблизно 30% транзакцій є простими переказами ефіру, а ще 25%-30% - переказами токенів ERC20, для яких зазвичай необхідно лише зчитувати та записувати обмежену кількість рахунків та сховищ. Для цих транзакцій результати моделювання мають стабільну точність.
На основі цих уявлень ми розробили трьохетапну паралельну структуру виконання для Grevm як продовження моделі Block-STM, поєднуючи дані з моделювання для отримання підказок про залежності транзакцій:
· Етап 1: Генерація підказок і попереднє завантаження стану - моделювання транзакцій для збору підказок про залежності та попереднього прогріву кешу пам'яті. Цей етап може виконуватися в різні моменти часу, залежно від дизайну блокчейну. Наприклад, коли нові транзакції надходять до пулу пам'яті, моделювання може бути виконано негайно для підготовки підказок про залежності.
· Етап 2: Аналіз залежностей - перетворення зібраних на етапі моделювання підказок про залежності на спрямований ациклічний граф (DAG), що представляє залежності між транзакціями. Цей DAG використовується для планування розкладу транзакцій у подальшому паралельному виконанні.
· Етап 3: Паралельне виконання в умовах конфлікту - використання модифікованого алгоритму BlockSTM на базі залежностей DAG для паралельного виконання транзакцій. Програма планування більше не вибирає транзакції строго за номером послідовності в блоці (наприклад, 1, 2, 3, ..., n), а віддає перевагу вибору транзакцій на основі DAG, щоб мінімізувати конфлікти та зменшити потребу в повторному виконанні.
Асинхронне пакетне подання стану
Генерація угоди про стан залишається критично важливим вузьким місцем у конвеєрі блокчейну, що зумовлено природною послідовністю меркельних обчислень. Обчислення кожного піддерева повинні завершитися, перш ніж генерувати остаточну угоду про стан, що призводить до значних затримок. Хоча існуючі рішення (такі як паралелізація на рівні рахунків у reth) вводять певну міру паралельності, ще залишається багато простору для оптимізації. У контексті реактора потоків блоків (BSR) Gravity reth угода про стан та виконання транзакцій можуть бути асинхронно обчислені, що уможливлює затримане та пакетне обчислення угоди про стан без блокування виконання.
Щоб вирішити ці проблеми, запропонована структура вводить такі ключові інновації:
Асинхронне пакетне хешування: використовуючи роз'єднання консенсусу стану та виконання транзакцій, ця структура реалізує асинхронне обчислення стану. Оновлення кореня стану здійснюється пакетами (наприклад, обчислюється кожні 10 блоків), щоб зменшити частоту обчислення кореня стану. Цей пакетний підхід забезпечує ефективне хешування спільних брудних вузлів, максимально зменшуючи накладні витрати частих оновлень і знижуючи загальні витрати на обчислення. Для малих блоків пакетна обробка може значно поліпшити паралельність; для великих блоків це може зменшити загальні витрати на обчислення.
Повна паралелізація: ця структура розширює паралелізацію на все дерево станів, а не лише на окремі дерева рахунків. Для позначених як «брудні» вузлів структура використовує алгоритм паралельного обчислення стану, розподіляючи дерево на незалежні піддерева та обробляючи ці піддерева паралельно. Результати агрегуються на верхньому рівні для ефективного обчислення остаточного кореня. Цей метод забезпечує, що великі блоки з великою кількістю транзакцій та змін стану можуть максимально використовувати багатопоточність, що максимізує пропускну здатність.
Альтернатива швидкому кореню стану: щоб адаптуватися до заголовків блоків Ethereum та операцій коду BLOCKHASH (які вимагають доступу до останніх 256 блоків стану), ми переосмислили корінь стану. На відміну від того, що залежить від остаточного стану (який недоступний під час виконання транзакцій), ми обчислюємо корінь стану як комбінацію набору змін блоку з попереднім коренем стану. Цей підхід пришвидшує обчислення кореня стану, не вимагаючи очікування завершення повного подання стану.
Gravity Store
Щоб задовольнити вимоги високопродуктивних блокчейнів до управління великими обсягами даних, Gravity Store виникає як оптимізований багатоверсійний рівень зберігання. Він ґрунтується на дизайні reth, який вже зменшив проблеми з роздуванням стану, розділивши зберігання даних стану та зберігання даних стану, одночасно знизивши накладні витрати на читання та запис даних. Однак виконавчий рівень Gravity reth потребує подальшої підтримки паралельної обробки та асинхронного подання стану, викликаючи більше технічних вимог.
Щоб вирішити ці виклики, Gravity Store пропонує ефективну багатоверсійність деревоподібної структури, спеціально розроблену для нашої архітектури BSR (Block Stream Reactor). Ця структура підтримує управління багатоверсійними оновленнями стану. У відмінності від традиційного підходу, при якому хеш-значення оновлюється відразу після зміни, Gravity Store маркує змінені вузли як «брудні», що дозволяє відкласти обчислення хешу та виконувати їх пакетами. Цей дизайн дозволяє швидко створювати нові версії, ефективно запитувати дані конкретних версій і очищати старі версії, які знаходяться нижче вказаного рівня, що значно підвищує продуктивність управління станами блокчейну.
Ми також досліджуємо незалежну розробку механізму зберігання Gravity DB, мета якого - забезпечити оптимізований рівень зберігання для блокчейн-додатків та підтримувати повністю асинхронні операції вводу/виводу. Дизайн цього механізму надихнув LETUS, високо продуктивний логічний структурований загальний механізм бази даних для блокчейн-додатків. Наш головний розробник Річард є одним із авторів LETUS і в найближчій публікації детально опише його дизайн.
Висновок
Gravity Chain - це високопродуктивний EVM-сумісний блокчейн першого рівня, розроблений для задоволення вимог до масштабованості та продуктивності сучасних веб3 додатків. У поєднанні з Gravity SDK, конвеєрним механізмом консенсусу AptosBFT та виконавчим рівнем Gravity reth, що керується Grevm, Gravity забезпечує пропускну здатність 1 gigagas на секунду, час підтвердження транзакцій за частки секунди та безпеку PoS на основі повторного стейкінгу. Ці технічні компоненти створюють надійну основу для створення кастомізованих альтернатив L1 або більш ефективних рішень L2 для веб3 додатків, особливо в контексті оптимізації використання EVM ланцюгів.
Ця стаття є результатом подачі, і не представляє думку BlockBeats.
