合意
取引は, Sumeragi がブロックに提案する前に並列に入ります.検証者は自主的に提案を検証し実行し,その後に再現できる状態の移行のみに署名します.必要な検証者数がその結果について同意した後でブロックがコミットし,対応する役に立たない荷物が利用可能になります.
すべての Iroha 3 ネットワークは,データ可用性と信頼性の高い放送経路を使用します.これらはコンセンサスの要求であり,オプションの展開機能ではありません.
Sumeragi
Sumeragi は, Iroha のバイザンティアンエラー耐性コンセンサスエンジンです. 順番からトランザクションを採取し,検証者同級生が同じオーダーされたブロックについて合意し,十分な検証者が同じ結果を再現してコミット証明書に署名した後のみそのブロックを完了します.
提案とコミットメントの経路
Sumeragi は,本簿を一度にブロックの高さで前方に運びます.各高さでは,1つの検証者が現在のビューの提案者として機能します.提案者は順番から適格な取引を取り出し,候補者ブロックを構築し,有効な検証者セットへの提案を発表します.
同様の Sumeragi パイプラインは,許可されたおよび指定されたステーク証明 (NPoS) の展開の両方で使用されます.
- 検証者は,排列の取引からブロックを提案します.
- 検証者は,同じ世界国に対する取引を実行することによって提案を検証します.
- 検証者は現在の高度と視野に対して投票と定数証明書を交換する.
- 一旦コンビートクォーラムに達すると 同級者はブロックを締結し 世界状態を更新します.
検証者は,本地的に再現できるデータのみをサインします.投票する前に,検証者は提案が予想されるチェーン,高度,ビューに属していることを確認し,取引の署名と制限が有効であることを確認し,レーンルーティングと実行者認証は決定的であることを確認します.当地結果が異なる場合,検証者は提案を賛成する代わりに拒否します.
投票は小さな署名された合意メッセージです.提案されたブロック,高度,ビュー,および検証者のアイデンティティを参照します.収集者はそれらの票をクオラム証明書またはコミット証明書に集約します.証明書は,同じブロックに対して十分な検証者が同じ結果を達成したことを示す永続的な証拠である.
クォーラム,コレクター,オブザーバー
nの投票検証者数でビザンティアの誤差予算が定義される.少なくとも4つの認証者を持つネットワークでは,予算は f = floor((n - 1) / 3)であり,コミットクオラムは 2f + 1.1~3つの検証器では,すべての認証器がコンビートで必要であり,開発に役立つが,オフラインでの実用的な緩みがない.
Sumeragi は,すべての他の検証者に各票を送信する代わりに,1つまたは複数の収集者を高度に選択することができます.収集者は投票を集めて,定数進捗を公表し,重複投票トラフィックの量を減らすことができます.効果的なコレクター設定は, GET /v1/sumeragi/collectors を経由して開示される. CLI のops sumeragi telemetry スナップショットは,現在のコレクターの数値を報告する.
観測者同級者はコミットブロックを同期できますが,提案したり,投票したり,票を収集したり,コンビートクォーラムにカウントしたりすることはありません. 展開にローカルクエリ能力,インデックス,モニタリング,または地域ブロック複製が必要な場合,投票検証者の数を増加せずに観察者を使用します.
変更と復元を表示する
ビューとは Sumeragi が特定の提案者とタイムプランで一つの高度を最終化しようとする試みである.提案,有用荷,投票,または進捗が停止した場合,ペースメーカーは高度を後期ビューに移動することができます.ビュー変更は約束されたブロックを再書き換えるものではありません.検証者は未約束の高度を完成させようとし,最も高い知られたクォーラムや証拠を提出する方法を変化させるため 同僚は矛盾するブロックを最終的に完了しない.
補給荷重復は最終決定から分離される.ペアが完全なブロック補給荷を入手する前にクオラムまたはコミット証明書を受け取る可能性があります.その場合,ペアは信頼性の高い放送 (RBC) またはブロック同期を使用して補給荷を取り戻し,広告されたハッシュに対して検証します.ブロックは,世界国および Kura に適用される.
合意モード
選択されたモードは,検証セットがどのように形成され操作されるかを制御します.これは consensus_modeを通じて創世文で宣言され,同等構成では sumeragi.consensus_modeによって宣言されます.ネットワーク全体の状態として扱います:検証者は同じ署名された起源,トポロジー,信頼性の高いピアデータ,有効な Sumeragi パラメータが必要です.
| モード | 最高のフィット | 検証器セット | 業務的焦点 |
|---|---|---|---|
| 許可された | 民間,コンソーシアムおよびオペレーター管理のネットワーク | 検証者は部署によって合意された信頼性の高いピアトポロジーから来ています | すべての検証者は同じ署名された起源,信頼できる同級者,同級鍵,および Sumeragi パラメータに保持してください. |
| NPOS | 公的または Nexus 向けネットワークで,認証はノミネート・ステークポリシーに続く | バリダーターはNPoSプロフィールによって選択され,通常は時代間隔で選択され, BLS キーと所有証明書が必要です | ステークス・スナップショット,時代パラメータ,検証器 PoPs,およびNPoSフェーズタイムアウトをネットワーク全体に並べます |
許可されたモード
認証者リストが明示的な操作的選択である場合,許可モードを使用します.これは自主ホスト Iroha ネットワークの通常の出発点です. 会員変更は故意なガバナンスまたは管理者のアクションだからです.重要な操作規則は,すべての検証者が起源,信頼できる同級者, BLS 所有証明および Sumeragi パラメータの同一視野で実行しなければならない.異なるトポロジーまたは署名された同級者を持つ単一の同級者はネットワークがコミットするのを防ぐことができる.
NPOSモード
NPoSモードを使用すると,デプロイメントプロフィールでは検証者の参加がノミネートおよびステートによって誘導されることを期待する.公共の SORA Nexus デプロイションはNPoSを使用し,生成されたプロファイルには BLS 認証者アイデンティティ,所有権証明書,時代設定が含まれます.Sumeragi NPoS パラメータは起動時に必要である. Epoch 変更は,定義された高度で設定したアクティブ 検証器を置き換えることができるため,オペレーターはコンセンサスの健康と次のリストに供給するステークまたはノミネーション状態の両方を監視する必要があります.
多国間合意
Iroha の多行コンセンサス経路は, Nexus レーンとデータスペースの設定を通じて実装されます.これは各レーンに対して別々のコンセンサスインスタンスを起動しません.Sumeragi はまだ1つの注文されたブロックストリームを完了します. लेनは,そのストリームの内部でトランザクションがどのようにルーティングされ,スケジュールされ,記録され,保存されるかを記述します.
ランタイム設定では,3つのレーン状態を構成します
lane_catalog: 構成された行列,それぞれ番号LaneId,別名,データスペース,可視性,ストレージプロフィール,証明スキーム,メタデータを持つ.dataspace_catalog:コンフィギュレーションされたデータスペース,それぞれが数値DataSpaceIdとリレー委員会サイズに使用される故障耐性値を有する.routing_policy: デフォルトレーン/データスペースペアと,アカウントや指示経路に一致する順序のルーティングルールを表示します.
トランザクションがキューに入ると,レーンルーターはそれを RoutingDecision { lane_id, dataspace_id } に解決します.シングルレーンモードでは,これは常にレーン 0であり,普遍的なデータ空間です.Nexus モードでは,設定されたルーターはデータスペーススケープのルール,決済ルーティング,アカウントルールは,明示的なルーティングルールを適用し,最後にデフォルトルートを使用します.解消されたレーンとデータスペースは,そのカタログに存在し,レーンは解消されたデータスペースに結びつかないといけない.そうでない場合,トランザクションが排列される前に拒否されます.
順番は,このルーティング決定をトランザクションハッシュで保持するので,後の段階では再推論する必要はありません.提案構造は,2つの方法でレーンメタデータを使用します:
- レーンごとに取引を交差します。1つの行列がブロックを支配しないのは その取引が最初に排列されたからだ.
- レーンごとにトランザクション実行ユニット (TEU) の制限が適用される.レーンの設定容量を上回るトランザクションは,ライヴロックを避けるために,レーンの最初の超重なトランザクションが認められる場合を除き,延期およびリクエウされます.
信頼性のある放送中に, Sumeragi はレーンとデータスペースによって提案された有用な負荷を集計する.記録された合計にはトランザクションカウント,放送ブロック,有用な負載バイト,および TEU が含まれます.コミットした後,これらの合計は, Sumeragi 状態を通じて暴露されるレーンとデータの空間へのコミットメントのスナップショットになります.ブロックにレーン決済領収書が含まれている場合,ブロック処理はまたレーン決算コミットメントとレリーエンベルを作成し,ブロックヘッダー,コンビート証明書,データ可用性コミットメントハッシュ,決済証明およびレーン役に立たない負荷サイズを結びつける.
信頼できる放送 (RBC)
信頼性の高い放送 (RBC) は, Sumeragi の有用荷の拡散と回収経路である.この経路は,検証者や観測者が提案に属するブロックボディを取得し,特に BlockCreated メッセージ,ブロック同期更新,または直接的有用荷転送が遅延または失われた場合に役立ちます.
RBC は役に立たない負荷レベルで動作します.提案者はブロック高度,ビュー,および役に立たない负荷ハッシュのための RBC セッションを発表し,その後,コミットトポロジー全体に役立つ負荷の塊を送信します.ピアは,断片の受信を追跡し,広告されたハッシュに対して回収した有用な負荷を検証し,同じ有効な負荷が十分に確認されると READYと DELIVER信号を交換します.セッションは TTL,チャック,ファヌアウト,ペンディング・スタッシュ,そして持続的なストア制限で制限されているため,復旧トラフィックが限界なく成長することはできません.
RBC は別々の合意決定ではなく,コミット証明書を置き換えることはありません. ブロックはまだ有効なコミット証明書と現地で対応する役に立たない場合にのみ終了します.RBC は,必須の可用性証明書と有用な負荷回収に貢献し,commit進捗は commit 証明書加上ローカル有用な負載によって導かれます.Certificate が payload より先に到着した場合, peer は RBC または block sync を介して payload を復旧し,その後 commit を行うことができます.
運用的には, RBC は,欠損の有用な負荷とデータ利用性のボトルネックを診断するのに役立つ.
iroha --output-format text ops sumeragi telemetryは,総可用投票,現在の収集者数,および待機中の RBC セッションを表示する.GET /v1/sumeragi/rbcそしてGET /v1/sumeragi/rbc/sessions詳細な総合データとアクティブセッションデータを公開する. Torii, 断片的な進歩,準備性,配達状態,レーンまたはデータスペースのバックログを含む.参照 Torii エンドポイント.- プロメテウス信号は
sumeragi_rbc_store_pressure,sumeragi_rbc_backpressure_deferrals_total, 経路またはデータ空間ごとに RBC バックログメーターは,ネットワーク損失,部品復元,およびストレージ圧力を分離するのに役立ちます. 性能と指標.
Kura ストレージ・レイアウトには,誘導レーン設定を使用します. 各レーンは, blocks/lane_000_core そして merge_ledger/lane_000_core_merge.log; レーンのライフサイクルの変更は,グローバルブロック順序を変えることなく,それらのセグメントを配置したり,退職したり,再標識することもできます.