Sei опублікувала нову білу книгу, в якій представлено останнє оновлення Giga. Більшості читачів здається, що глибокий технічний зміст на 17 сторінках важко читати. Тому ця стаття пояснить зміст цього оновлення та те, як підвищити продуктивність блокчейну на різних рівнях.
Про генерування блоків за допомогою асинхронного виконання
Основна ідея та основи Giga такі:
"Якщо наш список угод впорядкований, а початковий стан блокчейну узгоджений, і всі чесні вузли обробляють ці угоди в однаковому порядку, тоді вузли досягнуть одного і того ж остаточного стану."
У цьому випадку результат залежить лише від початкового стану та порядку транзакцій. Це означає, що консенсусу потрібно лише досягти згоди щодо порядку транзакцій у блоці, і кожен вузол може незалежно обчислювати остаточний стан.
У цій моделі консенсус відокремлюється від виконання, що дозволяє блокам виконуватись асинхронно.
Якщо блок остаточно затверджено, вузли оброблять його та подадуть свій стан у наступних блоках.
Потім через консенсус стану перевіряється цей блок, щоб забезпечити правильний фінальний стан, обчислений усіма вузлами.
Однією з важливих деталей є те, що виконання та консенсус (генерація) відбуваються паралельно. Під час виконання обчислень блоку вузол також отримує інші блоки.
Тому блоки насправді виконуються у загальному порядку (а не паралельно), а процес генерації блоків дійсно відбувається паралельно з консенсусом. Проте для будь-якого даного блоку ці процеси є повністю асинхронними.
Очевидно, що одночасно досягти консенсусу та виконати один і той же блок, здається, неможливо. Тому, під час виконання блоку n, вузол прийме блок n+1 для наступного кроку.
Якщо виникає розбіжність у консенсусі (наприклад, якщо третина вузлів у мережі діє зловмисно), ланцюг призупиняється, що подібно до стандартного протоколу BFT.
Транзакції, які не вдалися при виконанні в межах блоку, не роблять цей блок недійсним, а просто залишаються в стані невдачі, оскільки формування блоку та виконання відокремлені, а остаточний стан поточного блоку буде подано в наступних блоках.
Як реалізується модель з багатьма пропонуючими та що таке Autobahn?
Цей консенсусний протокол сам по собі називається «Autobahn» (так само, як безлімітна німецька автобана). Autobahn відокремлює доступність даних і впорядкування транзакцій, за чим стоїть цікавий модель.
Як і в будь-якому ряді смуг руху на автомагістралі, існує кілька смуг, і кожен вузол має свій канал. Вузли використовують ці канали, щоб висувати пропозиції щодо впорядкування транзакцій. Пропозиція - це просто впорядкована сукупність транзакцій.
Autobahn іноді виконує операцію «tipcut», тобто агрегує кілька пропозицій для остаточного визначення порядку транзакцій.
Як вже було сказано раніше, кожен валідатор має свій канал для пропозиції пакетів транзакцій.
Коли вузол отримує дійсну пропозицію, він надсилає голос, щоб підтвердити, що пропозиція отримана.
Після збору пропозицій для голосування формується доказ працездатності (PoA), що гарантує, що дані були отримані принаймні одним чесним вузлом у мережі.
Час виникнення Tipcut вимірюється в мілісекундах, і в кінцевому підсумку кілька пропозицій з Autobahn будуть «cut».
Пропонувальник має мотивацію чекати на випуск блоку та, за можливості, випустити окремий блок, але обмеження часу виконання для кожного блоку (схоже на обмеження Gas) трохи змінює цю динаміку.
Пропозиція на одному каналі зазвичай відповідає одному блоку, що означає, що коли відбувається Tipcut, декілька блоків будуть одночасно відсічені.
Після цього лідер слоту відправляє Tipcut іншим вузлам для завершення сортування. Вузли фактично вже готують наступний Tipcut, коли голосують за окремий Tipcut.
Пропущені вузли партії можуть асинхронно отримувати дані від валідаторів, перерахованих у PoA: це і є суттю потреби в доступності даних.
У синхронних умовах, якщо лідер правильний, Autobahn завершить підтвердження пропозицій за два раунди зв'язку. Якщо лідер зазнає збою, механізм обере нового лідера для підтримки процесу.
Наступна пропозиція tip-cut фактично може початися на стадії подання поточного tip-cut, що дозволить зменшити затримку, оскільки виконання відбувається паралельно з генерацією.
Насправді, вся модель є моделлю з кількома пропозиціями, в якій багато вузлів можуть одночасно пропонувати свої блоки для сортування. Кожен валідатор пропонує свій блок і отримує доказ (PoA) того, що мережа має ці блоки, що допомагає підвищити пропускну спроможність мережі та загальну ефективність.
Паралельне виконання та його застосування
Як вже згадувалося раніше, процес виконання блоку і консенсус відбуваються паралельно, хоча сам блок насправді виконується послідовно. Ви можете задатися питанням, чи є це справжнім паралельним виконанням.
Відповідь і ствердна, і заперечна.
У той час як блоки виконуються послідовно, транзакції всередині блоків дійсно можуть виконуватися паралельно. Якщо транзакції не змінюють (записують) один і той же стан, а результати однієї транзакції не впливають на іншу, то вони можуть виконуватися паралельно.
Коротко кажучи, їхні шляхи виконання не повинні залежати один від одного. У Giga немає пулу пам'яті, транзакції відразу включаються вузлами.
Giga припускає, що між більшістю транзакцій немає конфліктів, і обробляє ці транзакції одночасно на кількох процесорних ядрах.
Зміни кожної транзакції тимчасово зберігаються в приватному буфері і не застосовуються відразу до блокчейну.
Після обробки система перевірить, чи є конфлікт між цією транзакцією та попередніми.
Якщо виникне конфлікт, транзакцію буде повторно оброблено. Якщо конфлікту немає, її зміни будуть застосовані до блокчейну та остаточно затверджені.
Також можуть виникнути ситуації з частими конфліктами, у такому випадку система перейде до обробки однієї транзакції за раз, щоб забезпечити просування транзакції.
Простими словами, паралельне виконання розподіляє транзакції на кілька ядер, що дозволяє виконувати ті транзакції, які не мають конфліктів, одночасно.
Проблеми зберігання та оптимізація
Оскільки обсяги торгівлі є великими, дані повинні бути одночасно безпечними та легкодоступними, тому їх зберігання має бути трохи відмінним від традиційного зберігання в блокчейні. Giga зберігає дані у простому форматі ключ-значення, що є відносно пласкою структурою, що допомагає зменшити кількість оновлень або перевірок, необхідних при зміні даних.
Крім того, Giga використовує багаторівневе зберігання: недавні дані зберігаються на SSD (висока швидкість), тоді як менш використовувані дані переміщуються в більш повільні, але більш економічні системи зберігання.
Якщо якийсь вузол зламається, він може відтворити журнал, щоб відновити правильний стан, і застосувати оновлення до RocksDB (спеціалізованої бази даних) для організації даних.
Ця система зберігання використовує криптографічний акумulator, який може підтверджувати правильність даних без необхідності виконання громіздких обчислень. Акумulator оновлюється пакетним способом, що дозволяє валідаторам і легким вузлам швидко узгоджувати поточний стан блокчейну.
Що означає стати багатопропозиційним EVM L1 блокчейном?
Інфраструктура L1 може бути покращена різними способами, і різні L1 стикаються з різними технічними викликами, від економічних проблем, таких як MEV, до технічних проблем, таких як управління станом.
Як перший L1 ланцюг, що підтримує кілька пропозицій, це досить складно, особливо для EVM L1, оскільки початковий дизайн EVM не передбачав підтримки системи з кількома пропозиціями.
Однак Sei намагається знайти різні підходи для збереження EVM та багатьох інструментів, які звикли використовувати розробники.
Паралельне виконання транзакцій, досягнення консенсусу під час виконання та паралельна діяльність кількох пропонентів сприяють підвищенню продуктивності, пропускна здатність виконання може зрости приблизно в 50 разів. Однак ці вдосконалення також можуть стикатися з деякими ризиками, згаданими вище.
Це друге велике оновлення Sei, раніше Sei перетворилася з Cosmos ланцюга на EVM ланцюг, а тепер Sei запустила виконуючий клієнт, оптимізований для швидкості.
Подальший розвиток та наслідки цих оптимізаційних заходів заслуговують на увагу.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Інтерпретація нової Білой книги Sei: які технологічні інновації вводить оновлення Giga?
Автор: Павло Парамонов, засновник Hazeflow
Переклад: PANews
Sei опублікувала нову білу книгу, в якій представлено останнє оновлення Giga. Більшості читачів здається, що глибокий технічний зміст на 17 сторінках важко читати. Тому ця стаття пояснить зміст цього оновлення та те, як підвищити продуктивність блокчейну на різних рівнях.
Про генерування блоків за допомогою асинхронного виконання
Основна ідея та основи Giga такі:
"Якщо наш список угод впорядкований, а початковий стан блокчейну узгоджений, і всі чесні вузли обробляють ці угоди в однаковому порядку, тоді вузли досягнуть одного і того ж остаточного стану."
У цьому випадку результат залежить лише від початкового стану та порядку транзакцій. Це означає, що консенсусу потрібно лише досягти згоди щодо порядку транзакцій у блоці, і кожен вузол може незалежно обчислювати остаточний стан.
У цій моделі консенсус відокремлюється від виконання, що дозволяє блокам виконуватись асинхронно.
Якщо блок остаточно затверджено, вузли оброблять його та подадуть свій стан у наступних блоках.
Потім через консенсус стану перевіряється цей блок, щоб забезпечити правильний фінальний стан, обчислений усіма вузлами.
Однією з важливих деталей є те, що виконання та консенсус (генерація) відбуваються паралельно. Під час виконання обчислень блоку вузол також отримує інші блоки.
Тому блоки насправді виконуються у загальному порядку (а не паралельно), а процес генерації блоків дійсно відбувається паралельно з консенсусом. Проте для будь-якого даного блоку ці процеси є повністю асинхронними.
Очевидно, що одночасно досягти консенсусу та виконати один і той же блок, здається, неможливо. Тому, під час виконання блоку n, вузол прийме блок n+1 для наступного кроку.
Якщо виникає розбіжність у консенсусі (наприклад, якщо третина вузлів у мережі діє зловмисно), ланцюг призупиняється, що подібно до стандартного протоколу BFT.
Транзакції, які не вдалися при виконанні в межах блоку, не роблять цей блок недійсним, а просто залишаються в стані невдачі, оскільки формування блоку та виконання відокремлені, а остаточний стан поточного блоку буде подано в наступних блоках.
Як реалізується модель з багатьма пропонуючими та що таке Autobahn?
Цей консенсусний протокол сам по собі називається «Autobahn» (так само, як безлімітна німецька автобана). Autobahn відокремлює доступність даних і впорядкування транзакцій, за чим стоїть цікавий модель.
Як і в будь-якому ряді смуг руху на автомагістралі, існує кілька смуг, і кожен вузол має свій канал. Вузли використовують ці канали, щоб висувати пропозиції щодо впорядкування транзакцій. Пропозиція - це просто впорядкована сукупність транзакцій.
Autobahn іноді виконує операцію «tipcut», тобто агрегує кілька пропозицій для остаточного визначення порядку транзакцій.
Як вже було сказано раніше, кожен валідатор має свій канал для пропозиції пакетів транзакцій.
Коли вузол отримує дійсну пропозицію, він надсилає голос, щоб підтвердити, що пропозиція отримана.
Після збору пропозицій для голосування формується доказ працездатності (PoA), що гарантує, що дані були отримані принаймні одним чесним вузлом у мережі.
Час виникнення Tipcut вимірюється в мілісекундах, і в кінцевому підсумку кілька пропозицій з Autobahn будуть «cut».
Пропонувальник має мотивацію чекати на випуск блоку та, за можливості, випустити окремий блок, але обмеження часу виконання для кожного блоку (схоже на обмеження Gas) трохи змінює цю динаміку.
Пропозиція на одному каналі зазвичай відповідає одному блоку, що означає, що коли відбувається Tipcut, декілька блоків будуть одночасно відсічені.
Після цього лідер слоту відправляє Tipcut іншим вузлам для завершення сортування. Вузли фактично вже готують наступний Tipcut, коли голосують за окремий Tipcut.
Пропущені вузли партії можуть асинхронно отримувати дані від валідаторів, перерахованих у PoA: це і є суттю потреби в доступності даних.
У синхронних умовах, якщо лідер правильний, Autobahn завершить підтвердження пропозицій за два раунди зв'язку. Якщо лідер зазнає збою, механізм обере нового лідера для підтримки процесу.
Наступна пропозиція tip-cut фактично може початися на стадії подання поточного tip-cut, що дозволить зменшити затримку, оскільки виконання відбувається паралельно з генерацією.
Насправді, вся модель є моделлю з кількома пропозиціями, в якій багато вузлів можуть одночасно пропонувати свої блоки для сортування. Кожен валідатор пропонує свій блок і отримує доказ (PoA) того, що мережа має ці блоки, що допомагає підвищити пропускну спроможність мережі та загальну ефективність.
Паралельне виконання та його застосування
Як вже згадувалося раніше, процес виконання блоку і консенсус відбуваються паралельно, хоча сам блок насправді виконується послідовно. Ви можете задатися питанням, чи є це справжнім паралельним виконанням.
Відповідь і ствердна, і заперечна.
У той час як блоки виконуються послідовно, транзакції всередині блоків дійсно можуть виконуватися паралельно. Якщо транзакції не змінюють (записують) один і той же стан, а результати однієї транзакції не впливають на іншу, то вони можуть виконуватися паралельно.
Коротко кажучи, їхні шляхи виконання не повинні залежати один від одного. У Giga немає пулу пам'яті, транзакції відразу включаються вузлами.
Giga припускає, що між більшістю транзакцій немає конфліктів, і обробляє ці транзакції одночасно на кількох процесорних ядрах.
Зміни кожної транзакції тимчасово зберігаються в приватному буфері і не застосовуються відразу до блокчейну.
Після обробки система перевірить, чи є конфлікт між цією транзакцією та попередніми.
Якщо виникне конфлікт, транзакцію буде повторно оброблено. Якщо конфлікту немає, її зміни будуть застосовані до блокчейну та остаточно затверджені.
Також можуть виникнути ситуації з частими конфліктами, у такому випадку система перейде до обробки однієї транзакції за раз, щоб забезпечити просування транзакції.
Простими словами, паралельне виконання розподіляє транзакції на кілька ядер, що дозволяє виконувати ті транзакції, які не мають конфліктів, одночасно.
Проблеми зберігання та оптимізація
Оскільки обсяги торгівлі є великими, дані повинні бути одночасно безпечними та легкодоступними, тому їх зберігання має бути трохи відмінним від традиційного зберігання в блокчейні. Giga зберігає дані у простому форматі ключ-значення, що є відносно пласкою структурою, що допомагає зменшити кількість оновлень або перевірок, необхідних при зміні даних.
Крім того, Giga використовує багаторівневе зберігання: недавні дані зберігаються на SSD (висока швидкість), тоді як менш використовувані дані переміщуються в більш повільні, але більш економічні системи зберігання.
Якщо якийсь вузол зламається, він може відтворити журнал, щоб відновити правильний стан, і застосувати оновлення до RocksDB (спеціалізованої бази даних) для організації даних.
Ця система зберігання використовує криптографічний акумulator, який може підтверджувати правильність даних без необхідності виконання громіздких обчислень. Акумulator оновлюється пакетним способом, що дозволяє валідаторам і легким вузлам швидко узгоджувати поточний стан блокчейну.
Що означає стати багатопропозиційним EVM L1 блокчейном?
Інфраструктура L1 може бути покращена різними способами, і різні L1 стикаються з різними технічними викликами, від економічних проблем, таких як MEV, до технічних проблем, таких як управління станом.
Як перший L1 ланцюг, що підтримує кілька пропозицій, це досить складно, особливо для EVM L1, оскільки початковий дизайн EVM не передбачав підтримки системи з кількома пропозиціями.
Однак Sei намагається знайти різні підходи для збереження EVM та багатьох інструментів, які звикли використовувати розробники.
Паралельне виконання транзакцій, досягнення консенсусу під час виконання та паралельна діяльність кількох пропонентів сприяють підвищенню продуктивності, пропускна здатність виконання може зрости приблизно в 50 разів. Однак ці вдосконалення також можуть стикатися з деякими ризиками, згаданими вище.
Це друге велике оновлення Sei, раніше Sei перетворилася з Cosmos ланцюга на EVM ланцюг, а тепер Sei запустила виконуючий клієнт, оптимізований для швидкості.
Подальший розвиток та наслідки цих оптимізаційних заходів заслуговують на увагу.