Інтерпретація нової Білої книги Sei: Які технологічні інновації вводить оновлення Giga?

Автор: Павло Парамонов, засновник Hazeflow

Переклад: Felix, PANews

Sei випустила новий білл, в якому представлено останнє оновлення Giga. Більшість читачів вважають, що 17 сторінок глибокого технічного змісту важко читати. Тому ця стаття пояснить зміст цього оновлення та те, як підвищити продуктивність блокчейну на різних рівнях.

1. Про блоки, що генеруються асинхронно

Основна ідея та основа Giga такі:

"Якщо наш список транзакцій впорядкований, а початковий стан блокчейна однаковий, і всі чесні вузли обробляють ці транзакції в одному й тому ж порядку, то вузли досягнуть однакового кінцевого стану."

У цьому випадку результат залежить лише від початкового стану та порядку транзакцій. Це означає, що консенсусу потрібно досягти лише щодо порядку транзакцій у блоці, кожен вузол може самостійно обчислити остаточний стан.

• У цій моделі консенсус відокремлюється від виконання, що дозволяє блокам виконуватися асинхронно.
• Як тільки блок остаточно визначено, вузли оброблять його і подадуть його стан у наступних блоках.
• Потім перевіряється блок через консенсус стану, щоб упевнитися, що всі вузли обчислили правильний остаточний стан.

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

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

Очевидно, що одночасно досягти консенсусу та виконати один і той самий блок, здається, неможливо. Тому, під час виконання блоку n, вузол отримує блок n+1 для наступного кроку.

Якщо в консенсусі виникає розбіжність (наприклад, якщо третина вузлів у мережі діє зловмисно), ланцюг буде призупинено, що схоже на стандартний протокол BFT.

Транзакції, які не виконалися в блоці, не роблять цей блок недійсним, а лише зберігають стан невдачі, оскільки генерація блоку та виконання відокремлені, і остаточний стан поточного блоку буде підтверджений у наступних блоках.

2. Як реалізується модель з багатьма пропозиціонерами та Autobahn що це таке?

Цей консенсусний протокол сам по собі називається "Autobahn" (як безлімітна німецька автобана). Autobahn відокремлює доступність даних і впорядкування транзакцій, за яким стоїть цікавий модель.

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

Autobahn іноді виконує операцію "tipcut", тобто агрегує кілька пропозицій для остаточного визначення порядку транзакцій.

• Як вже згадувалося раніше, кожен валідатор має свій канал для пропозиції партій транзакцій.
• Коли вузол отримує дійсну пропозицію, він надсилає голосування для підтвердження того, що пропозиція отримана.
• Збір пропозицій після голосування сформує доказ верифікації (PoA), що підтверджує, що дані були отримані принаймні одним чесним вузлом у мережі.
• Час виникнення Tipcut вимірюється в мілісекундах, зрештою кілька пропозицій з Autobahn будуть "cut.".

Пропоненти мають стимул чекати на випуск блоку та за можливості випустити окремий блок, але обмеження часу виконання для кожного блоку (схоже на обмеження Gas) трохи змінює цю динаміку.

Пропозиція на одному каналі зазвичай відповідає одному блоку, що означає, що коли відбувається Tipcut, кілька блоків можуть бути одночасно відсічені.

Після цього лідер слота надсилає Tipcut іншим вузлам для завершення сортування. Вузли насправді вже готують наступний Tipcut, одночасно голосуючи за окремий Tipcut.

Пропущені вузли партії можуть асинхронно отримувати дані від валідаторів, перерахованих у PoA: саме це є суттю потреби в доступності даних.

У синхронних умовах, якщо лідер правильний, Autobahn завершить підтвердження пропозиції за два раунди зв'язку. Якщо лідер зазнає збоїв, механізм обере нового лідера для підтримки процесу.

Наступна пропозиція tip-cut насправді може початися на стадії подання поточного tip-cut, що дозволяє зменшити затримку, оскільки виконання відбувається паралельно з генерацією.

Насправді, вся модель є моделлю з кількома пропозиціями, де багато вузлів можуть одночасно пропонувати свої блоки для впорядкування. Кожен валідатор пропонує свій блок і отримує підтвердження (PoA) на те, що мережа має ці блоки, що допомагає підвищити пропускну здатність мережі та загальну ефективність.

3. Паралельне виконання та його застосування

Як уже згадувалося раніше, процес виконання блоку та консенсус відбуваються паралельно, хоча сам блок насправді виконується послідовно. Ви можете запитати, чи це складає справжнє паралельне виконання.

Відповідь одночасно ствердна і заперечна.

Хоча блоки виконуються в порядку, транзакції всередині блоку дійсно можуть виконуватися паралельно. Якщо транзакції не змінюють (не записують) один і той же стан, і результат однієї транзакції не впливає на іншу транзакцію, то вони можуть виконуватися паралельно.

Коротше кажучи, їхні шляхи виконання не повинні залежати один від одного. У Giga немає пулу пам'яті, транзакції негайно включаються вузлом.

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

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

Простими словами, паралельне виконання розподіляє транзакції між кількома ядрами, що дозволяє транзакціям без конфліктів виконуватись одночасно.

4. Проблеми зберігання та оптимізації

Оскільки обсяги торгівлі великі, дані повинні бути як безпечними, так і легкодоступними, тому спосіб їх зберігання має дещо відрізнятися від традиційного зберігання в блокчейні. Giga зберігає дані у простому форматі ключ-значення (key-value), що є відносно плоскою структурою, яка допомагає зменшити кількість оновлень або перевірок, необхідних при зміні даних.

Крім того, Giga використовує ієрархічне зберігання: нещодавні дані зберігаються на SSD (швидкісний), тоді як менш використовувані дані переміщуються до більш повільних, економічніших систем зберігання.

Якщо якийсь вузол зазнає краху, він може відтворити журнал, щоб відновити правильний стан, і застосувати оновлення до RocksDB (спеціалізованої бази даних) для організації даних.

Ця система зберігання використовує криптографічний акумулятор (Cryptographic Accumulator), який може підтверджувати правильність даних без необхідності проводити складні обчислення. Акумулятор оновлюється в пакетному режимі, що дозволяє перевіряючим особам та легким вузлам швидко досягати згоди щодо поточного стану блокчейну.

5. Що означає стати мульти-пропозиціонером на EVM L1 блокчейні?

Інфраструктура L1 може бути вдосконалена різними способами, а різні L1 стикаються з різними технічними викликами - від економічних питань, таких як MEV, до технічних проблем, таких як управління станом.

Як перший L1 ланцюг, що підтримує кілька пропозицій, це є досить складним завданням, особливо для EVM L1, оскільки первісне призначення EVM не передбачає підтримки системи з кількома пропозиціями.

Однак Sei намагається використовувати різні підходи для збереження EVM та багатьох інструментів, які звикли використовувати розробники.

Паралельне виконання транзакцій, досягнення консенсусу під час виконання та паралельна робота кількох пропонентів сприяють підвищенню продуктивності, пропускна здатність виконання може зрости приблизно в 50 разів. Однак ці покращення можуть також стикатися з деякими ризиками, згаданими вище.

Це друге велике оновлення Sei, раніше Sei перетворився з ланцюга Cosmos на EVM ланцюг, а тепер Sei випустив виконавчий клієнт, оптимізований для швидкості.

Подальший розвиток та наступні ефекти цих оптимізаційних заходів заслуговують на увагу.

Додаткова інформація: Дослідження продуктивності, відповідності та взаємодії блокчейну Sei