Розробка кастомного консенсус-механізму
Більшість проектів, які приходять з запитом "розробіть нам свій консенсус", насправді не потребують кастомного консенсусу. Їм потрібен application-specific chain з модифікованими параметрами: інший block time, інші правила включення транзакцій, кастомний mempool. Це вирішується через Cosmos SDK або OP Stack без написання нового консенсусного протоколу. Справжній кастомний консенсус — це 1–2 років роботи команди з досвідчених distributed systems інженерів та формальна верифікація коректності. Це важливо розуміти до початку технічного обговорення.
Коли реально потрібен кастомний консенсус
Легітимні випадки: спеціалізована мережа з нестандартними вимогами до продуктивності (> 100k TPS, deterministic finality < 100мс), консорціумні мережі з кастомними правилами валідації учасників, дослідницькі/академічні проекти, експериментальні механізми (VDF-based randomness, threshold signatures as consensus).
У більшості випадків простіше взяти існуючий алгоритм та адаптувати його. Розберемо архітектурне простір вибору.
Таксономія консенсусних протоколів
Classical BFT: pBFT та похідні
pBFT (Practical Byzantine Fault Tolerance, Castro & Liskov, 1999) — перший практичний BFT алгоритм. O(n²) повідомлень, працює при < n/3 Byzantine nodes. У чистому вигляді не масштабується за ~20 nodes через communication overhead.
Сучасні похідні:
- HotStuff (використовується в LibraBFT/DiemBFT/Jolteon): лінійна комунікаційна складність O(n), лідерська схема з pipelining. Facebook/Meta використовували для Diem.
- 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 варіанти: в PoS "обчислювальна робота" замінюється stake. 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 {
// Розширює locked branch АБО QC вище ніж lockedQC
return block.QC.Height > n.lockedQC.Height ||
n.extendsLockedBlock(block)
}
BLS threshold signatures
Агрегація підписів через BLS12-381 криву — стандарт для сучасних BFT протоколів. Threshold scheme (t з n): кожен validator підписує своїм ключем, агрегатор збирає 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 лідером — найскладніший аспект. У 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 місяців.