# MonadBFT

MonadBFTは、ビザンチンアクターの存在下で部分同期条件下でトランザクションの順序付けに関する合意を達成するための高性能コンセンサス メカニズムです。これは、[Jolteon](https://arxiv.org/pdf/2106.10362.pdf) / [DiemBFT](https://developers.diem.com/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2021-08-17.pdf) / [Fast-HotStuff](https://arxiv.org/abs/2010.11454)で提案された改良点を備えた[HotStuff](https://arxiv.org/pdf/1803.05069.pdf)の派生製品であり、リーダータイムアウトの場合に二次通信の複雑さを利用することで3ラウンドから2ラウンドに削減されます。

MonadBFTは、楽観的な応答性を備えたパイプライン化された2フェーズBFTアルゴリズムであり、一般的な場合には線形通信オーバーヘッドがあり、タイムアウトの場合には二次通信が行われます。ほとんどのBFTアルゴリズムと同様、通信は段階的に進行します。各フェーズで、リーダーは署名付きメッセージを有権者に送信し、有権者は次のリーダーに署名付きの回答を送信します。パイプライン処理により、ブロックのクォーラム証明書(QC)またはタイムアウト証明書(TC)が`k`ブロックの提案に便乗できるようになります。`k+1.`

## 簡単な事実 <a href="#quick-facts" id="quick-facts"></a>

| シビル耐性のメカニズム | プルーフ・オブ・ステーク (PoS) |
| ----------- | ------------------ |
| ブロックタイム     | 1秒                 |
| ファイナリティ     | シングルスロット           |
| 委任が許可される    | はい                 |

## Mempool <a href="#mempool" id="mempool"></a>

[Shared Mampool](https://neafs-organization.gitbook.io/japanads-doc/na/konsensasu/shared-mempool)を参照してください。

## コンセンサスプロトコル <a href="#consensus-protocol" id="consensus-protocol"></a>

MonadBFTは、ラウンドで進行するパイプライン化されたコンセンサスメカニズムです。以下の説明は、プロトコルの高レベルで直感的な理解を示します。

通常のように、`n = 3f+1`ノードが存在するとします。ここで、 は`f`ビザンチン ノードの最大数です。つまり、`2f+1`ノードの (つまり 2/3) が非ビザンチンです。以下の説明では、すべてのノードが等しいステーク ウェイトを持つものとして扱います。実際には、すべてのしきい値はノード数ではなくステークの重みで表すことができます。

* 各ラウンドで、リーダーは新しいブロックと、前のラウンドの QC または TC (これについては後ほど詳しく説明します) を送信します。
* 各バリデータは、そのブロックがプロトコルに準拠しているかどうかを確認し、同意した場合は、署名付きの賛成票を次のラウンドのリーダーに送信します。そのリーダーは、バリデーターからの YES 投票を (しきい値署名を介して) 集約することで QC (クォーラム証明書) を導き出します`2f+1`。この場合の通信は*線形で*あることに注意してください。リーダーはブロックをバリデーターに送信し、バリデーターは投票を次のリーダーに直接送信します。
  * あるいは、バリデーターが事前に指定された時間内に有効なブロックを受信しない場合、署名付きタイムアウト メッセージを*すべて*のピアにマルチキャストします。このタイムアウト メッセージには、バリデーターが観察した最高の QC も含まれています。いずれかのバリデーターがタイムアウト メッセージを蓄積すると`2f+1`、これらを (やはりしきい値署名を介して) TC (タイムアウト証明書) に組み立て、次のリーダーに直接送信します。
* `k`各バリデータは、ラウンドの QC を受信すると`k+1`(つまり、ラウンドのリーダーからの通信で`k+2`)、ラウンドで提案されたブロックを確定します。具体的には：
  * ラウンド のリーダーであるアリスは`k`、新しいブロックを全員に送信します (ラウンド の QC または TC とともに`k-1`、これは重要ではないので無視しましょう)。
  * `2f+1`バリデーターが Bob (ラウンド のリーダー) に投票を送信してそのブロックに YES 投票した場合`k+1`、ブロックには`k+1`ラウンド の QC が含まれます`k`。ただし、`k` *この時点で*ラウンドの QC を確認しただけでは、ラウンド内のブロックが保存されたことをバリデーターのヴァレリーが知るには十分ではありません`k`。(たとえば) ボブが悪意を持ってブロックをヴァレリーに送信しただけである可能性があるためです。ヴァレリーができることは、ブロックに投票し、チャーリー (ラウンドのリーダー)`k+1`に投票を送ることだけです。`k+2`
  * `2f+1`バリデーターがブロックで YES に投票した場合`k+1`、チャーリーはラウンドの QC`k+1`とラウンドのブロック提案を公開します`k+2`。ヴァレリーはこのブロックを受け取るとすぐに、ラウンドからのブロック`k`(アリスのブロック) が確定したことを知ります。
  * ボブが、round で無効なブロック提案を送信するか`k+1`、少数のバリデータに送信するなど、悪意のある行動をとったとします`2f+1`。次に、少なくとも`f+1`バリデーターがタイムアウトになり、次に他の非ビザンチンバリデーターがタイムアウトをトリガーし、少なくとも 1 つのバリデーターがラウンドの TC を生成するようになります`k+1`。次に、チャーリーは提案書でラウンドの TC を公開します`k+1`(ラウンドに利用できる QC がないため、提案を行うためにはそうする必要があります`k+1`)。
  * このコミット手順を 2 チェーン コミット ルールと呼びます。これは、バリデーターが 2 つの隣接する認証済みブロック および を確認するとすぐに`B`、その先祖すべてを`B'`コミットできるためです。`B`

参考文献:

* マオファン・イン、ダリア・マルキ、マイケル・K・ライター、ガイ・ゴラン・グエタ、イッタイ・エイブラハム。[HotStuff: ブロックチェーンの視点から見る BFT コンセンサス](https://arxiv.org/abs/1803.05069)、2018 年。
* モハマド・M・ジャラルザイ、牛建宇、チェン・フェン、ファンユー・ガイ。[Fast-HotStuff: 高速かつ復元力のある HotStuff プロトコル](https://arxiv.org/abs/2010.11454)、2020 年。
* ラティ・ゲラシヴィリ、レフテリス・ココリス＝コギアス、アルベルト・ソンニーノ、アレクサンダー・シュピーゲルマン、卓倫翔。[Jolteon と同上: 非同期フォールバックによるネットワーク適応型の効率的なコンセンサス](https://arxiv.org/pdf/2106.10362.pdf)。 arXiv プレプリント arXiv:2106.10362、2021。
* ディエムチーム。[DiemBFT v4: Diem ブロックチェーンのステート マシン レプリケーション](https://developers.diem.com/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2021-08-17.pdf)。 2021年。

## BLS マルチシグネチャ <a href="#bls-multi-signatures" id="bls-multi-signatures"></a>

証明書(QC および TC)は、secp256k1曲線上のECDSA署名のベクトルとして単純に実装できます。これらの証明書は明示的であり、構築と検証が簡単です。ただし、証明書のサイズは署名者の数に比例します。投票メッセージを除くほぼすべてのコンセンサス メッセージに証明書が含まれるため、スケーリングに制限が生じます。

BLS12-381曲線上のペアリングベースのBLSシグネチャは、スケーリングの問題の解決に役立ちます。署名は段階的に1つの署名に集約できます。単一の有効な集約署名を検証すると、公開鍵に関連付けられたステークがすべてメッセージに署名していることが証明されます。

BLS署名はECDSA署名よりもはるかに低速です。したがって、パフォーマンス上の理由からMonadBFTは、BLS署名が集約可能なメッセージ タイプ(投票とタイムアウト)でのみ使用される混合署名スキームを採用しています。メッセージの整合性と信頼性は、引き続きECDSA署名によって提供されます。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://neafs-organization.gitbook.io/japanads-doc/na/konsensasu/monadbft.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.