Розробка кастомного консенсус-механізму під ключ

Розробка кастомного консенсус-механізму

Більшість проєктів, які приходять із запитом «розробіть нам свій консенсус», насправді не потребують кастомного консенсусу. Їм потрібен application-specific chain з модифікованими параметрами: інший block time, інші правила включення транзакцій, кастомний mempool. Це вирішується через Cosmos SDK або OP Stack без написання нового консенсусного протоколу. Справжній кастомний консенсус — це 10–18 місяців роботи команди з досвідчених distributed systems інженерів і формальна верифікація коректності. Ми допоможемо вам оцінити проєкт і підібрати оптимальне рішення — від адаптації існуючого протоколу до повної розробки під ключ. Отримайте консультацію по вашому проєкту — пишіть, ми оцінимо терміни та складність.

Коли реально потрібен кастомний консенсус?

Легітимні випадки: спеціалізована мережа з нестандартними вимогами до продуктивності (> 100k TPS, deterministic finality < 100мс), консорціумні мережі з кастомними правилами валідації учасників, дослідницькі/академічні проєкти, експериментальні механізми (VDF-based randomness, threshold signatures as consensus). У більшості випадків простіше взяти існуючий алгоритм і адаптувати його. Розглянемо архітектурний простір вибору.

Як вибрати консенсус-механізм для вашого проєкту?

Taxonomy консенсусних протоколів

Classical BFT: pBFT і похідні

pBFT (Practical Byzantine Fault Tolerance, Castro & Liskov, кінець минулого століття) — перший практичний BFT алгоритм. O(n²) повідомлень, працює при < n/3 Byzantine nodes. У чистому вигляді не масштабується за ~20 nodes через communication overhead.

Сучасні похідні:

• HotStuff (використовується в LibraBFT/DiemBFT/Jolteon): лінійна комунікаційна складність O(n), лідерська схема з pipelining. HotStuff потребує в 2 рази менше повідомлень, ніж pBFT, що економить комісії на внутрішньомережевий трафік.
• Tendermint/CometBFT: round-based, deterministic finality per block, використовується в Cosmos SDK. Дві фази: prevote та precommit. Потребує > 2/3 voting power для finality.
• PBFT з threshold signatures: замінюємо n²-комунікацію агрегацією через BLS threshold signatures — кожен валідатор підписує BLS ключем, агрегатор збирає threshold підписів в одну.

Nakamoto Consensus і похідні

PoW Nakamoto — probabilistic finality, fork choice rule (longest chain / most work). Ніколи не фінальний, але практично необоротний після достатньої кількості підтверджень. Простота — головна перевага.

GHOST protocol (Greedy Heaviest-Observed Subtree): fork choice враховує uncle blocks, не тільки main chain. Використовується в Ethereum (Gasper — комбінація GHOST + Casper FFG).

Proof-of-Stake variants: у PoS «обчислювальна робота» замінюється стейком. Validator selection через VRF (Verifiable Random Function) — Algorand, Cardano Ouroboros.

DAG-based консенсус

Hashgraph (Hedera): події організовані в DAG, віртуальне голосування без повідомлень. Детермінований алгоритм з DAG-структури обчислює consensus timestamp і order.

Narwhal/Bullshark (Sui): Narwhal — DAG-based mempool з certified availability (кожен блок сертифікується 2f+1 підписами). Bullshark — інтерпретує DAG для ordering. Розділення data dissemination і ordering.

Mysticeti (новий консенсус Sui): прибирає лідера з критичного шляху, знижує latency.

Порівняння підходів

Порівняння мов реалізації консенсусу

Реалізація: приклад HotStuff-inspired протоколу

Розглянемо ключові компоненти при реалізації BFT-консенсусу на Go:

Структури даних

type Block struct { Height uint64 ParentHash [32]byte Txns []Transaction QC *QuorumCertificate // доказательство попереднього блоку Timestamp int64 ProposerID NodeID } type QuorumCertificate struct { BlockHash [32]byte Height uint64 Signatures []BLSSignature // threshold агрегований підпис Signers []NodeID } type Vote struct { BlockHash [32]byte Height uint64 Round uint32 VoterID NodeID Signature BLSSignature } 

Три фази HotStuff

HotStuff організовує консенсус у трьох фазах (prepare, pre-commit, commit) з pipelining — поки блок k проходить commit, блок k+1 проходить pre-commit, блок k+2 — prepare:

type HotStuffNode struct { id NodeID height uint64 lockedQC *QuorumCertificate // locked на pre-commit фазі preparedQC *QuorumCertificate // prepared на prepare фазі privateKey bls.PrivateKey validators ValidatorSet } func (n *HotStuffNode) onReceiveProposal(block *Block) { // Safety rule: прийняти тільки якщо block.QC >= n.lockedQC if block.QC.Height < n.lockedQC.Height { return // відхиляємо } // Liveness rule: прийняти якщо block.QC >= n.preparedQC // або block розширює locked block if !n.safeNode(block) { return } vote := n.createVote(block) n.sendToleader(vote) } func (n *HotStuffNode) safeNode(block *Block) bool { // Extends locked branch OR QC вище ніж lockedQC return block.QC.Height > n.lockedQC.Height || n.extendsLockedBlock(block) } 

BLS threshold signatures

Агрегація підписів через криву BLS12-381 — стандарт для сучасних BFT протоколів. Threshold scheme (t з n): кожен валідатор підписує своїм ключем, агрегатор збирає t підписів і створює один агрегований підпис, верифікований одним публічним ключем:

import "github.com/herumi/bls-eth-go-binary/bls" func aggregateSignatures(sigs []bls.Sign) bls.Sign { var agg bls.Sign agg.Add(&sigs[0]) for i := 1; i < len(sigs); i++ { agg.Add(&sigs[i]) } return agg } func verifyQC(qc *QuorumCertificate, validators ValidatorSet) bool { pubkeys := make([]bls.PublicKey, len(qc.Signers)) for i, id := range qc.Signers { pubkeys[i] = validators.GetPublicKey(id) } aggPubkey := bls.AggregatePubkeys(pubkeys) return qc.Signatures[0].VerifyHash(&aggPubkey, qc.BlockHash[:]) } 

View Change: обробка збоїв лідера

Liveness під Byzantine lider — найскладніший аспект. У HotStuff view change відбувається при timeout:

func (n *HotStuffNode) onTimeout(view uint32) { // Broadcast timeout message з поточним lockedQC timeout := TimeoutMsg{ View: view, LockedQC: n.lockedQC, SenderID: n.id, Sig: n.sign(view, n.lockedQC), } n.broadcast(timeout) } func (n *HotStuffNode) onReceiveTimeouts(timeouts []TimeoutMsg) { if len(timeouts) < n.validators.QuorumSize() { return } // Новий лідер — node з найбільшим view в round-robin або VRF newLeader := n.electLeader(timeouts[0].View + 1) if newLeader == n.id { // Вибираємо найвищий QC з timeout messages highQC := n.highestQC(timeouts) n.proposeBlock(highQC) } } 

Чому формальна верифікація критична?

Для production консенсусного протоколу — обов'язкова формальна верифікація safety і liveness properties. Інструменти:

TLA+ — мова формальної специфікації. Специфікуємо safety invariant: «два чесних вузли не можуть закомітити різні блоки на одній висоті». TLC model checker перевіряє на всіх досяжних станах при n ≤ 5–7 nodes.

Ivy — мова для верифікації distributed protocols. Команда Hedera використовувала для Hashgraph. Coq/Lean — для proof assistant підходу.

Без формальної верифікації кастомний консенсус не повинен використовуватися в production з реальними активами. Історія blockchain повна прикладів консенсусних багів, виявлених роками пізніше (Ethereum Byzantium fork bugs, нещодавні Cosmos SDK консенсусні вразливості).

Мережевий рівень: P2P transport

Консенсусні повідомлення потребують low-latency доставки. Protobuf серіалізація обов'язкова (JSON занадто повільний для consensus-critical messages). Transport:

libp2p — стандарт де-факто в Web3. GossipSub для broadcast, Direct streams для unicast. Використовується в Ethereum, Filecoin, Polkadot.

QUIC/gRPC — для більш контрольованих P2P топологій (enterprise blockchain).

Стек і терміни

Мова реалізації: Go (Tendermint, Ethereum CL) або Rust (Solana, NEAR, Polkadot substrate) — обидві мають зрілі BLS libraries та p2p стеки.

Реалістичні етапи:

• Специфікація і формальна модель в TLA+: 4–6 тижнів
• Базова реалізація happy path: 8–12 тижнів
• View change і Byzantine fault handling: 8–12 тижнів
• Тестування (chaos testing, Byzantine fault injection): 8–12 тижнів
• Formal verification: 4–8 тижнів
• Security audit: 6–8 тижнів

Разом: 10–18 місяців до production-ready консенсусу. Адаптація існуючого (CometBFT/HotStuff reference impl) з кастомними параметрами — 3–6 місяців.

Процес розробки кастомного консенсусу під ключ

1. Аналіз вимог і вибір архітектури — 1–2 тижні.
2. Формальна специфікація на TLA+ — 4–6 тижнів.
3. Реалізація happy path на Go/Rust — 8–12 тижнів.
4. Реалізація view change і Byzantine fault handling — 8–12 тижнів.
5. Тестування з chaos і Byzantine injection — 8–12 тижнів.
6. Формальна верифікація — 4–8 тижнів.
7. Security audit — 6–8 тижнів.
8. Розгортання testnet і написання документації — 2–4 тижні.

Що входить в роботу

• Повний цикл розробки: від архітектурного проектування до деплою в mainnet.
• Формальна специфікація і верифікація (TLA+ / Coq).
• Опенсорсні або комерційні BLS-бібліотеки.
• Інтеграція з libp2p/gossipsub.
• Навантажувальне тестування і симуляція Byzantine сценаріїв.
• Security audit (спільно з партнерами).
• Документація для розробників і операторів.
• Навчання вашої команди.

Отримайте консультацію по вашому проєкту — пишіть, ми оцінимо терміни та складність. Розробка під ключ з гарантією формальної коректності.