最初のレベルのタイトル

プロトコルの概要

最初のレベルのタイトル

HotStuff の主要なイノベーション

スター型通信ネットワークにより、HotStuff BFT/LibraBFT は通信の複雑さを軽減しながらラウンドの複雑さを増加させながらコンセンサスを達成することができます。注目に値する主な革新は次のとおりです。

1. HotStuff 参加者は、p2p チャネル (スター トポロジ通信ネットワーク) を通じてリーダーに署名されたメッセージを送信します。

2.HotStuff は、リーダーが正しいか間違っているかに関係なく、線形認証子の複雑さを実現できるしきい値デジタル署名スキームを使用します。

最初のレベルのタイトル

信頼できるリーダーの重要性

HotStuff BFT プロトコルには明確な意思決定メッセージ伝播プロセスが欠けているため、メッセージ伝播の重要性は特に顕著です。リーダーが HotStuff で決定メッセージを確実にブロードキャストできない場合、問題が発生します。次のような状況です。

合意によれば、リーダーのタスクはパスを (a0->a1->…->->b) に拡張することです。実行がうまくいったと仮定して、次のビュー v+1 に進みます。リーダーがコマンドをすべての参加者に伝播し、すべての参加者が拡張リーフ ノード b および c に関連付けられたコマンドを実行するようにします。 HotStuff BFT プロトコルには、「事実上、遅れている受信者は、欠落しているノードを他のレプリカからフェッチすることで追いつくことができます。」と記載されています。これは、ビュー v+1 の終わりに、遅れている参加者が (a0-> a1->... で追いつくことができることを意味します) ->->b->c) 対応する prepareQC。

ただし、追いつこうとしている参加者には、すべての参加者が実際にコマンドを実行したかどうか (つまり、リーダーがノード b のコマンドを全員、ノード、または一部のサブセットに伝播したかどうか) を知る方法がありません。 HotStuff BFT プロトコルによれば、ツリー上のノードには親ノードのハッシュ値とクライアント コマンドのみが含まれます。その結果、各アクターによって維持されるリーフ ノードには、コマンドが実行されたかどうかに関する情報が含まれません。

最後に、この分析では、HotStuff の元の概要では、ネットワーク上の参加者に不一致が発生しやすく、特定のコマンドが実行されたかどうかがツリー ノードに含まれているかどうかを考慮する必要があることが明らかになりました。