Moonshot Consensus: Optimistic Proposal for Blockchain-Based State Machine Replication (Moonshot Consensus: Оптимістична пропозиція щодо реплікації стану на основі блокчейну)

15 min readJul 31, 2024

Оригінал статті тут.

Зміст

1.Блокчейни та Консенсус
2. Налаштування Проблеми
3. Представлення Moonshot
— Tendermint
— Jolteon
— Chained Moonshot
4. Доказово Покращена Продуктивність
5. Moonshot просуває передові технології

Завантажити Whitepaper pdf | Переглянути презентації

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

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

Поява Bitcoin у 2008 році проклала шлях для сучасної блокчейн-індустрії. Сьогодні існує багато публічних блокчейнів, і ця сфера продовжує зростати захоплюючи.

Блокчейни та Консенсус (Blockchains and Consensus)

Отже, що таке блокчейн? Блокчейн — це по суті тип розподіленої бази даних. Ця база даних веде зростаючий журнал завершених транзакцій, які надсилаються користувачами системи, коли вони хочуть взаємодіяти з нею. Що саме можуть робити ці транзакції залежить від можливостей конкретного блокчейну, але завжди існує якийсь побічний ефект. Ці побічні ефекти оновлюють іншу частину бази даних, що називається станом блокчейну, яка відслідковує інформацію, що важлива для користувачів. Мета мережі блокчейн — забезпечити, щоб всі комп’ютери в мережі, часто називані вузлами чи нодами, обробляли ті ж самі транзакції в одному і тому ж порядку, щоб досягти одного і того ж стану.

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

Коли вузол додає новий блок до свого локального блокчейну, цей блок вважається таким, що має певну ступінь фінальності. Деякі блокчейни, такі як Bitcoin і його похідні, гарантують лише ймовірну фінальність. Наприклад, коли вузол Bitcoin додає новий блок до свого локального блокчейну, є ймовірність, що його доведеться замінити через те, що валідатори колективно створюють довший ланцюг, який не включає цей блок. Оскільки вузли Bitcoin зобов’язані приймати найдовший ланцюг, з яким вони ознайомлені, якщо це трапиться, вузол буде змушений змінити своє уявлення про ланцюг, щоб залишатися частиною канонічної мережі.

Інші мережі мають інші правила для досягнення того ж ефекту. Однак, для цілей цієї статті нас конкретно цікавлять протоколи консенсусу блокчейн, які досягають детерміністичної фінальності. Ці протоколи забезпечують, що якщо будь-який вузол закріплює новий блок у свій блокчейн, то йому ніколи не доведеться замінювати цей блок на інший. Ці протоколи формально відомі як протоколи реплікації стану машини (State Machine Replication, SMR).

Більш точно, протоколи SMR забезпечують, що якщо будь-які два чесні процеси закріплять блок у одній і тій же позиції в своїх відповідних локальних блокчейнах, то ці два блоки є однаковими. Цю властивість називають Безпекою (Safety). Ці протоколи також забезпечують, що валідатори продовжують додавати нові блоки до своїх локальних блокчейнів, поки мережа продовжує функціонувати. Цю властивість називають Живучістю (Liveness).

Є різні типи протоколів SMR, але сьогодні нас конкретно цікавлять ті, що впорядковують блоки по одному за раз, явно пов’язуючи кожен блок з його безпосереднім попередником. Ми будемо називати ці типи протоколів SMR протоколами SMR на основі блокчейну (blockchain-based SMR protocols).

На рисунку вище зображено процес консенсусу протоколу SMR на основі блокчейну. Протокол починається з того, що один з валідаторів, зображений тут як білі кола, створює блок зі свого локального пулу транзакцій і пропонує його своїм колегам як кандидата на додавання до блокчейну. Ми називаємо цього валідатора лідером. Решта валідаторів працюють над створенням доказу канонічності для цієї пропозиції, конструкція якого залежить від протоколу. Будь-який вузол, який спостерігає цей доказ (commits), додає відповідний блок до свого локального блокчейну, включаючи всі транзакції та застосовуючи їх побічні ефекти до свого стану, як показано на рисунку нижче.

Налаштування Проблеми (Problem Setting)

Сьогодні ми представляємо сімейство протоколів SMR на основі блокчейну Moonshot, нову колекцію протоколів консенсусу, що характеризуються оптимістичною пропозицією (Optimistic Proposal). Ми зосередимося на Chained Moonshot, першому протоколі з родини Moonshot. Розпочнемо з визначення налаштувань, для яких створено Moonshot.

Протоколи Moonshot, як і багато інших протоколів консенсусу блокчейну, є стійкими до вад у системі (Byzantine Fault Tolerant, BFT). Це означає, що вони продовжать функціонувати коректно, навіть якщо деякі валідатори зламаються або відхиляться від протоколу. Ми називаємо валідаторів, які діють таким чином, вадними (Byzantine), а тих, хто слідує протоколу, чесними (honest).

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

Неофіційно, протоколи Moonshot витримують до однієї третини валідаторів, які стають вадними. Точніше, ми вимагаємо, щоб загальна кількість валідаторів у мережі n задовольняла умову n ≥ 3 f + 1 , де f — кількість вадних валідаторів. Для цього матеріалу ми будемо припускати, що n=3 f + 1 і будемо використовувати термін кворум для групи з 2 f + 1 або більше валідаторів.

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

Конкретно, Moonshot функціонує в частково синхронному середовищі. Обмежена синхронна мережа (Bounded Synchronous network) — це така, де є відомий верхній межа Δ на затримку між відправленням повідомлення від відправника і його отриманням отримувачем. На відміну від цього, Асинхронна (Asynchronous) мережа — це така, де немає часових обмежень на затримку доставки повідомлень.

Модель часткової синхронії (Partially Synchronous) знаходиться на перетині цих двох моделей. Є кілька варіантів часткової синхронії, але ми конкретно розглядаємо той тип, який вважаємо найбільш репрезентативним для реальних публічних мереж. У цій версії часткової синхронії мережа може чергувати періоди асинхронії та синхронії. Ми називаємо моменти, коли мережа переходить від асинхронії до синхронії, глобальними стабілізаційними часами (Global Stabilization Times, GSTs). Ви знайдете більш формальне трактування цього визначення в нашій технічній статті.

Поки ми використовуємо Δ для представлення верхньої межі на затримку доставки повідомлень після GST, ми використовуємо δ для представлення середньої затримки доставки після GST. Відповідно, δ ≤ Δ залежно від поведінки супротивника.

Представлення Moonshot

Давайте розглянемо деякі існуючі протоколи SMR на основі блокчейну, які працюють в такому ж середовищі, як Moonshot, щоб зрозуміти інтуїцію за технікою Optimistic Proposal Moonshot. Ми оцінюватимемо ці протоколи з точки зору затримки фіналізації блоків, періоду блоків та складності повідомлень (також відомої як комунікаційна складність, communication complexity). Ми визначаємо період блоків як час між пропозиціями блоків, а затримку фіналізації блоків як час між пропозицією блоку та його підтвердженням більшістю чесних валідаторів. Ми вимірюємо комунікаційну складність асимптотично, приблизно оцінюючи кількість повідомлень, необхідних для досягнення консенсусу по одному блоку в термінах n.

Конкретно, щоб зберегти простоту, ми будемо зосереджені на Нормальному Шляху (Normal Path) кожного з цих протоколів. Протокол вважається в своєму Нормальному Шляху (іноді називається Швидким Шляхом — Fast Path, Щасливим Шляхом — Happy Path або Стійким Станом — Steady State), коли немає переривань у процесі консенсусу. Порівняно, протокол входить у свій Резервний Шлях (Fallback Path), коли він не може досягти угоди по інстанції консенсусу після певного часу, виміряного в термінах Δ , що може статися через асинхронність мережі або вадних лідерів. Ці протоколи найбільш ефективні під час роботи в їх Нормальних Шляхах, тоді як їх Резервні Шляхи дозволяють досягти Життєздатності. Ми детальніше розглянемо Резервні Шляхи цих протоколів у майбутньому контенті.

Протокол Tendermint

Протокол Practical Byzantine Fault Tolerance (PBFT) був розроблений Мігелем Кастро (Miguel Castro) і Барбарою Лісков (Barbara Liskov), і був опублікований у статті на конференції OSDI у 1999 році. PBFT був першим опублікованим рішенням для Byzantine Fault-Tolerant SMR в умовах часткової синхронізації. Багато років потому, PBFT був адаптований до блокчейн-середовища у протоколі Tendermint. Cosmos і багато блокчейнів у його екосистемі в даний час використовують цей протокол як свій механізм консенсусу.

На відміну від Moonshot, який передбачає пов’язану мережу та те, що комунікація між різними валідаторами відбувається безпосередньо через точкові зв’язки, Tendermint передбачає, що повідомлення надсилаються через протокол госсипу. Тому для справедливої порівняння ми будемо розглядати варіант Tendermint, який працює в такому ж середовищі, як Moonshot. Відповідно, ми передбачаємо, що коли валідатор Tendermint отримує раніше не бачене повідомлення від одного з його колег, він негайно пересилає це повідомлення всім іншим.

Це надає протоколу комунікаційну складність O ( n 3 ), оскільки кожен процес отримує O ( n ) унікальних голосів, коли система функціонує нормально. Ми визнаємо, що може існувати більш ефективний варіант Tendermint для точкових зв’язків, але використовуємо цю реалізацію, оскільки вона є простою і ми впевнені, що вона зберігає гарантії, які забезпечує оригінальний протокол госсипу (gossip protocol). Ми залишаємо це пересилання поза наступною діаграмою для зручності читання.

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

Крок 1: Лідер будує новий блок транзакцій, що розширює останній підтверджений блок, і пропонує його, розсилаючи іншим 3 валідаторам у повідомленні Proposal (називається Pre-Prepare у статті Tendermint).

Крок 2: Валідатори надсилають свої підтримки цієї пропозиції — голоси Prepare — кожному іншому валідатору. Наприкінці Кроку 2, валідатори отримують один голос Prepare від кожного з колег. Вони збирають кворум цих голосів і формують Сертифікат Кворуму Prepare (Prepare QC), потім блокується відповідний блок.

Крок 3: Після формування Prepare QC, на його основі валідатори надсилають свої другі підтримки пропозиції — голоси Commit (називаються Pre-Commit у статті Tendermint) — один одному. Знову ж, вони збирають кворум цих голосів і формують Commit QC. Commit QC слугує доказом канонічності блоку, дозволяючи вузлам, які спостерігають його, зафіксувати відповідний блок.

Після Кроку 3 валідатори переходять до нового раунду, і процес повторюється. Це надає Нормальному Шляху Tendermint такі характеристики:

Затримка фіналізації блоку (Block Finalization Latency): Tendermint фіналізує блок за 3 δ .
Період блоку (Block Period): Tendermint створює один блок кожні 3 δ .
Комунікаційна складність (Communication Complexity): Валідатори Tendermint повинні надіслати O ( n 3 ) повідомлень для досягнення консенсусу щодо блоку.

Два раунди голосування в Tendermint допомагають йому досягти властивості Безпеки SMR. Prepare QC, що створюється у першому раунді голосування, доводить, що більшість чесних валідаторів вважає новий блок дійсним. Commit QC, що створюється у другому раунді, доводить, що більшість чесних валідаторів знають про це і зафіксували відповідний блок. Правило голосування Tendermint гарантує, що якщо валідатор зафіксував блок, то він не голосуватиме за жоден інший блок, що пропонується для того ж самого положення або висоти в блокчейні.

Оскільки QCs потребують 2 f + 1 голосів з 3 f + 1 , якщо блок досягає Commit QC, то будь-який інший блок, що пропонується для тієї ж висоти, отримає не більше ніж 2 f голосів, навіть якщо Byzantine валідатори голосують за обидва блоки. Однак це правило є досить суворим, заважаючи конкуренції та ускладнюючи Liveness без гарантій, що надаються протоколом госсипу Tendermint. Пізніші протоколи послаблювали цю вимогу, як ми побачимо.

Jolteon

Розглянемо сучасний SMR протокол Jolteon, який демонструє концепцію конвеєризації раундів (ound pipelining) і, як і Tendermint, має два фази голосування. Jolteon працює в Нормальному Шляху наступним чином:

Крок 1. Як і Tendermint, лідер створює блок B₁ і транслює його всім учасникам.
Крок 2. Валідаори надсилають голоси підготовки для цього блоку. Але замість широкого розповсюдження голосів, їх надсилають безпосередньо лідеру наступного раунду, який агрегує ці голоси і створює QC як раніше.
Крок 3. Цей лідер створює новий блок, включаючи QC для B₁ як доказ, що блок розширює останній прийнятий блок в мережі. Після цього всі валідаори отримують QC для B₁, що дозволяє їм зафіксувати B₁.
Кроки 4 і 5. Кроки 2 і 3 повторюються для створення Prepare QC для B₂, який служить Commit QC для B₁ і досягає всіх валідаорів разом з пропозицією лідера B₃, що дозволяє їм зафіксувати B₂ і підтвердити B₁.

Як видно, Jolteon відрізняється від Tendermint у кількох аспектах. По-перше, він дозволяє лідерам пропонувати блоки на основі Prepare QC для пропозиції попередника. Це дозволяє протоколу досягати консенсусу по кількох блоках одночасно, що є значною оптимізацією в порівнянні з строго послідовним прогресом Tendermint. Це, в свою чергу, дозволяє зменшити кількість необхідних повідомлень для досягнення консенсусу шляхом об’єднання голосів підготовки і підтвердження в одне повідомлення, при цьому голоси підготовки для B₂ також відповідають голосам підтвердження для B₁, принаймні в Нормальному Шляху. Цю оптимізацію, вперше введену в Chained HotStuff, ми називаємо QC chaining.

Однак, перша оптимізація має деякі побічні ефекти, включаючи потенційні загрози для Безпеки. Jolteon долає ці загрози через змінену умову підтвердження, яка називається Правило Двох Ланцюгів Commit (Two-Chain Commit Rule). Це правило вимагає, щоб вузол підтвердив блок B, запропонований для раунду r, і всі його непідтверджені предки в порядку зростання висоти, лише якщо він спостерігає QCs для двох послідовних блоків B і B’, де B’ був запропонований для r+1 і включає QC для B.

Коротше кажучи, це означає, що якщо будь-який вузол активує Правило Двох Ланцюгів з B, то принаймні f+1 чесних валідаорів повинні зафіксувати B перед тим, як голосувати за будь-який блок, запропонований після B. Правила голосування Jolteon трохи складніші, ніж у Tendermint, тому без занурення в деталі, це в свою чергу гарантує, що кожний майбутній сертифікований блок (тобто блок, який досягає QC) обов’язково продовжить B.

Нарешті, в той час як валідаори Tendermint транслюють свої голоси, Jolteon покладається на агрегатора голосів. HotStuff, предок Jolteon, спочатку ввів концепцію агрегації голосів, щоб отримати протокол, який міг би досягти консенсусу в Нормальному Шляху, незважаючи на те, що валідаори спілкуються лише з одним іншим валідаором під час фаз голосування. Точніше кажучи, мета HotStuff полягала в досягненні Нормальної Складності повідомлень для кожного інстансу консенсусу O(n).

Однак використання одного валідаора для агрегації голосів також означає, що іншим валідаорам потрібно більше часу, щоб дізнатися результат, оскільки їм доводиться чекати, поки агрегатор надішле їм QC. Як результат, протоколи на основі агрегатора, такі як HotStuff і Jolteon, фактично розділяють фазу голосування на два етапи. Таким чином, хоча Лідер 3 на схемі вище може фіналізувати B₁ через 4δ після його пропозиції Лідером 1, решта валідаорів повинні чекати додаткове δ, щоб зробити те ж саме.

Підсумовуючи, Jolteon досягає наступного в Нормальному Шляху:

Затримка фіналізації блоку (Block Finalization Latency): Jolteon фіналізує блок за 5δ.
Період блоку (Block Period): Jolteon виробляє один блок кожні 2δ.
Складність комунікації (Communication Complexity): Валідаори Jolteon повинні надіслати O(n) повідомлень для досягнення консенсусу по блоку.

Chained Moonshot

Це підводить нас до Moonshot. Протоколи Moonshot роблять наступний крок у розширенні можливостей Chained HotStuff та його похідних завдяки новій оптимізації, яку ми називаємо Оптимістичним Пропозицією (Optimistic Proposal). Ця техніка є такою ж простою, як і звучить: замість того щоб чекати QC для блоку, запропонованого попередником, лідер Moonshot створює свою власну пропозицію, щойно отримує блок. Це дозволяє протоколу розпочати новий інстанс консенсусу кожні δ в Нормальному Шляху, що є оптимальним періодом блоку для протоколу SMR на основі блокчейну.

Chained Moonshot є варіантом Moonshot, який, як і Jolteon, реалізує QC chaining з Chained HotStuff. Однак він відмовляється від підходу з агрегатором голосів, віддаючи перевагу моделі трансляції, подібній до Tendermint та інших протоколів, схожих на PBFT, для досягнення кращої затримки фіналізації блоку. Подивимося, як працює його Нормальний Шлях:

Крок 1. Як і раніше, перший лідер транслює новий блок B₁.
Крок 2. Як у Tendermint, валідатори транслюють свої голоси за B₁. Проте, додатково, лідер наступного раунду одночасно пропонує B₂, посилаючись на B₁ як на його батька, включаючи стислий підсумок, званий дайджестом B₁, у B₂ (наприклад, криптографічний хеш B₁). Після отримання кворуму голосів за B₁ валідатори його фіксують і переходять до наступного раунду.
Крок 3. Надалі крок 2 повторюється, і третій лідер пропонує B₃, поки валідатори транслюють свої голоси за B₂. Після фіксації QC для B₂ валідатори додатково комітять B₁.

Важливо, що валідатор Chained Moonshot голосує за блок, запропонований під час Нормального Шляху, тільки якщо він вже зафіксований на своєму батьку. Крім того, валідатор Chained Moonshot може зафіксувати блок, запропонований для раунду r, лише якщо він спостерігає QC для цього блоку, перебуваючи в r+1, що є раундом, в якому дозволено голосувати за блок, і до переходу до Резервний Шлях (Fallback Path). Це, разом з Правилом Двох Ланцюгів Комітів — модифікованим для вимоги, щоб B’ містив дайджест B, а не QC для B — гарантує Безпеку Нормального Шляху.

На відміну від нашої спрощеної версії Tendermint, Fallback Path Chained Moonshot гарантує, що валідаторам не потрібно повторно транслювати кожне повідомлення, яке вони отримують, щоб протокол досяг Лівнесу. Однак його трансляція голосів все ще надає протоколу складність комунікації O(n²) повідомлень на рішення в Нормальному Шляху.

Підсумовуючи, Chained Moonshot має такі характеристики при нормальному функціонуванні:

Затримка фіналізації блоку (Block Finalization Latency): Chained Moonshot фіналізує блок за 3δ.
Продуктивність блоку (Block Throughput): Chained Moonshot виробляє один блок кожні δ.
Складність комунікації (Communication Complexity): Валідатори Chained Moonshot повинні надсилати O(n²) повідомлень для досягнення консенсусу щодо блоку.

Наступна фігура узагальнює властивості Нормальних Шляхів Tendermint, Jolteon та Chained Moonshot:

Доказово Покращена Продуктивність (Demonstrably Improved Performance)

Ми реалізували Chained Moonshot та перевірили наші теоретичні прогнози, модифікувавши реалізацію Jolteon, доступну в реалізації Narwhal-HotStuff, наданій Facebook Research. Потім ми порівняли цю реалізацію з існуючою реалізацією Jolteon, розділивши обидві від Narwhal, щоб переконатися, що наші вимірювання не були вплинуті поведінкою mempool.

Ми враховували дві метрики: продуктивність блоків (block throughput) та затримку фіналізації блоків (block finalization latency). Продуктивність блоків вимірювалася шляхом підрахунку кількості блоків, зафіксованих принаймні 2f+1 валідаторами, а затримка фіналізації вимірювалася як час між створенням блоку лідером та його фіксацією 2f+1-м валідатором.

Ми тестували мережі розміром від 10 до 200 вузлів та розміри блоків від 1.8kB до 18MB. Ми запускали кожен тест у AWS на екземплярах m5.xlarge, розгорнутих глобально в кількох регіонах, використовуючи 5 регіонів для тестів з 10 та 50 вузлами, і 20 регіонів для тестів з 100 та 200 вузлами. Кожну конфігурацію ми запускали протягом 5 хвилин, повторюючи кожен тест тричі для допомоги в усуненні виняткових значень. Ми спостерігали наступні результати.

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

Проте покращення продуктивності Chained Moonshot було меншим, ніж очікувалося. Воно забезпечило мінімум 24,5%, максимум 78,4% і в середньому 54,9% вищу продуктивність у всіх конфігураціях, що не дотягнуло до очікуваного 100% покращення, яке передбачалося порівнянням теоретичного періоду блоків з Jolteon.

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

Порівняно з цим, покращення латентності комміту в Chained Moonshot було ще кращим, ніж 40% зниження, яке передбачалося порівнянням теоретичної латентності фіналізації блоків з Jolteon. Chained Moonshot продемонстрував мінімальне покращення на 22,8%, максимальне на 58,7% та середнє на 41,1% у всіх конфігураціях.

Комбінування результатів для цих двох метрик дає графік, представлений нижче. Цей графік показує пропускну здатність обох протоколів, виміряну в байтах, що фіналізуються за секунду, порівняно з їхньою середньою латентністю фіналізації блоків. Обидві осі мають логарифмічний масштаб, що допомагає підкреслити відносні відмінності в продуктивності при менших розмірах корисного навантаження. За винятком графіків для мережі з 10 вузлами, кожна точка на графіку відповідає одному з розмірів корисного навантаження з осі x попередніх двох графіків, причому розмір корисного навантаження збільшується вздовж лінії, що починається з нуля на осі x. Ми додали додатковий розмір корисного навантаження в 180MB до набору тестів для мережі з 10 вузлами для цієї метрики, щоб допомогти прояснити тенденцію.

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

В цілому, цей графік ясно показує, що Chained Moonshot демонструє вищу пропускну здатність із нижчою латентністю у всіх конфігураціях. Більше того, він також забезпечує вищу точку насичення для розмірів мереж, які досягають насичення. Детальніше обговорення наших експериментів з Chained Moonshot і Jolteon ви знайдете в нашому технічному whitepaper.

Moonshot просуває передові технології

На завершення, Chained Moonshot є новим удосконаленням над Jolteon, сучасним протоколом консенсусу для блокчейн-технологій. Він поєднує трансляцію голосів і конвеєризацію пропозицій, щоб забезпечити низьку латентність і високу пропускну здатність, особливо коли мережа перебуває в сприятливих умовах. Це коротке введення опустило багато деталей протоколу, включаючи його поведінку у присутності візантійських збоїв. Ми також ще не обговорили інші варіанти Moonshot, над деякими з яких ми ще працюємо.

Ми незабаром випустимо більше матеріалів з цих тем, але поки що ми закликаємо всіх зацікавлених читачів поглибити знання, прочитавши останню версію нашого технічного документу та обговорюючи з нами в нашому Discord. До зустрічі незабаром!

Оригінал статті: