CometBFT 構造解説

Takami Torao CometBFT 0.37.2 #Blockchain #CometBFT #Tendermint #Cosmos
  • このエントリーをはてなブックマークに追加

概要

CometBFT は強い一貫性を持つ分散システムを構築するためのソフトウェアおよびその SDK (software development kit)。プライベート/コンソーシアムブロックチェーン用途に特化している。同じ名前の CometBFT または旧名の Tendermint-BFT と呼ばれる BFT (Byzantine fault tolerance; ビザンチン障害耐性) 特性を持つコンセンサスアルゴリズムを実装し、ステートマシン・レプリケーションによるトランザクション直列化でブロックチェーンのブロックを生成することを目的としている。

CometBFT は、以前は Tendermint Core として開発されていたが Tendermint の商標や権利を有する All in Bits (AiB) が v0.35 以降のリリースを放棄してリポジトリをアーカイブすることを決定したため、Tendermint Core のリポジトリを新たにフォークして CometBFT として開発することとなった [1]。したがって CometBFT は実質的に Tendermint の次パージョンであり、このプロジェクトには Cosmos SDK, IBC, および Interchain を構成する多数のエンジニアリングチームが参加している。

Table of Contents

  1. 概要
  2. 目次
  3. ソースリーディングのメモ
  4. 参照

目次

CometBFT: データ構造

2023年8月16日(Wed) CometBFT 0.37.2 #Blockchain #CometBFT #Tendermint #Cosmos

CometBFT: P2P ネットワーク

P2P ネットワーク機能は (例えばコンセンサスアルゴリズムのように) CometBFT ノードが協調しながら進行する必要のある処理のためのフレームワークである。基本はアクターモデルに似た設計であり、ノード間のメッセージングから TCP のような下層の通信レイヤーの詳細を隠蔽し、メッセージの配信とそれを処理するリアクター (サービス) という概念に抽象化する。…

2023年7月25日(Tue) CometBFT 0.37.2 #Blockchain #CometBFT #Tendermint #Cosmos

CometBFT: Mempool

mempool (メモリプール, メムプール) は未確定のトランザクション (unconfirmed transaction) を他のノードと共有し、提案ブロックの生成が行われるまで一時的に保存することを目的とした CometBFT の機構である。…

2023年7月10日(Mon) CometBFT 0.37.2 #Blockchain #CometBFT #Tendermint #Cosmos

CometBFT: コンセンサス

分散システムにおけるコンセンサスとは、分散ネットワーク上のすべての正常なノード間で合意を形成して共通の状態を確立するためのメカニズムである。よりブロックチェーン向けの表現では、コンセンサスに参加しているノードが「提案されたブロックを受理 (または拒否)」という共通の結論に到達するためのメカニズムを意味する。…

2023年7月10日(Mon) CometBFT 0.37.2 #Blockchain #CometBFT #Tendermint #Cosmos

CometBFT: ABCI

ABCI (application blockchain interface) は CometBFT コアの各コンポーネント (コンセンサス層) とブロックチェーンアプリケーションの実装 (アプリケーション層) が通信するためのインターフェース仕様である。…

2023年7月30日(Sun) CometBFT 0.37.2 #Blockchain #CometBFT #Tendermint #Cosmos

ソースリーディングのメモ

  • 全体: ランタイム経過時間の算出がことごとく time.Time を使った time.Duration であるためマシンの時刻調整が行われると問題が起きる可能性が非常に高い。特に時間が戻ったとき。
  • P2P: PEX の通信は暗号化されているか? プレーンな TCP であれば中間者が不正なアドレスセットにすり替えるポイズニングが可能。SecretConnection を使用している? 要確認。
  • P2P: PEX リアクターから RequestAddrs を行うタイミングが、1) AddPeer でピアが追加されたとき、2) crawlPeers で接続したとき、3) ensurePeers で接続したときの 3 箇所あるが、crawlPeers/ensurePeers の接続時にも AddPeer が呼ばれるため RequestAddrs は重複呼び出しになっている。
  • ABCI: client.ReqRes がやりたいことは Promise/Future パターンだと思うが、エラーを返すことができない設計になっている。
  • ABCI: 現在の実装では Async 接尾辞であっても実際は逐次で実行され結果をコールバックしているだけの偽の非同期だが、本当に非同期であれば 1 スレッドからの逐次呼び出しで応答順序は逆転する可能性がある。この場合、BeginBlockSync, DeliverTxAsync*, EndBlockSync の順だと、DeliverTx の応答が返ってくる前に EndBlock の応答が返ってくると DeliverTx の結果の取りこぼしが発生する。
  • アプリケーション実装とは、ABCI 経由で呼び出すプログラム、または main から始まる最上位の制御を指す。
  • デフォルト設定とは cometbft init で作成される config.toml での設定を指す。

参照

  1. The Interchain Foundation, Cosmos, meet CometBFT, Feb 2 2023