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

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

Більшість проєктів, які приходять із запитом «розробіть нам свій консенсус», насправді не потребують кастомного консенсусу. Їм потрібен 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 (спільно з партнерами).
• Документація для розробників і операторів.
• Навчання вашої команди.

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