I.はじめに
目的: fisco-bcos (v2.8.0) 環境のノード コンセンサスに対するブラックリストの影響をテストします。
4 ノード チェーンを展開して構築し、コンソールを展開します。
https://fisco-bcos-documentation.readthedocs.io/zh_CN/release-2.8.0/docs/installation.html
getPeersノードに接続されている p2p 接続のリストを取得します。
getSealerListコンセンサス ノードのリストを取得します。
CA ブラックリストの紹介:
CA ブラックリストを構成します。
2. 試験工程
毎回コンソールを介してノード nodeX に接続し、ノード nodeX がコンソールでトランザクションを送信できなくなるまで、p2p ネットワーク接続を 1 つずつ切断するという目的を達成するために、nodeX ノードのブラックリスト機能を介して他のノードを 1 つずつ追加します。 、次の 1 つのノードに切り替えます。
具体的には、次のプロセスは node0 から開始し、コンソールは node0 のみに接続され、node0 のブラックリストに node3、node2、node1 を 1 つずつ徐々に設定し、node0 のブラックリストが node1 に設定されると、node0 は完全に切断されます。他のノードとの p2p 接続; この時点で、コンソールはノード 0 に接続しなくなり、手動でノード 1 に切り替え、ノード 1 ノードのブラックリストに対して繰り返し操作を実行し、最終的にコンソールが各ノードに接続してコンセンサスを形成できなくなり、トランザクションを送信できません。
4 ノード環境では、
- 最初は、ブラックリストはありません。コンソールは node0 に接続され、トランザクションは正常に送信されます。すべてのノード ログは "
[CONSENSUS][SEALER]++++++++++++++++ Generating seal on,blkNum=28" コンセンサス ログを出力し続けます。getPeers の結果は 3 です。sealerList は node0-node3 です。 - 次に、node0 のブラックリストに node3 を設定し、node0 を再起動します。コンソールは node0 に接続され、トランザクションは正常に送信されます。すべてのノード ログは引き続きコンセンサス ログを出力します。getPeers の結果は 2 です。sealerList は node0-node3 です。
- 次に、node0 のブラックリストで node2 の構成を続行し、node0 を再起動します。コンソールは node0 に接続され、トランザクションは正常に送信されます。すべてのノード ログは引き続きコンセンサス ログを出力します。getPeers の結果は 1 です。sealerList は node0-node3 です。
- 続けて、node0 のブラックリストに node1 を設定し、node0 を再起動します。(1) コンソールが node0 に接続され、トランザクションがタイムアウトになりました。node0 はコンセンサス ログを出力しなくなり、他のノードは以前のコンセンサス ログを出力し続けます。getPeers の結果は空です。sealerList は node0-node3 です。(2) コンソールが node1 に接続され、トランザクションが正常に送信されます。
- 続行し、node2 を node1 のブラックリストに追加して、node1 を再起動します。コンソールは node1 に接続され、トランザクションを正常に送信できます。node1-node3 は引き続きコンセンサス ログを出力します。getPeers の結果は 1 です。sealerList は node0-node3 です。
- 続行し、node3 を node1 のブラックリストに追加して、node1 を再起動します。(1) コンソールが node1 に接続され、トランザクションがタイムアウトになりました。すべてのノードがコンセンサス ログを出力しなくなりました。getPeers の結果は空です。sealerList はまだ node0-node3 です。(2) コンソールが node2 に接続され、トランザクションがタイムアウトしました。現時点では、pbft コンセンサス要件が満たされておらず、全体的なコンセンサスに欠陥があります。
暫定的な結論:
- 上記のステップの予備分析によると、ブラックリストによって制御される p2p 接続は getSealerList の結果には影響しませんが (コンセンサス コマンドがアクティブに呼び出されない限り)、全体的なコンセンサス条件に影響を与え、最終的にコンセンサスを利用できなくなる可能性があります。
- 4が1にリンクされている場合、正常に動作している3つのノードは必ずしもペアで相互接続する必要はなく(上の5番目の写真のように)、トランザクションも正常に送信できます。
- 最終ノードの p2p 接続環境が pbft コンセンサス条件を満たさない場合、クラスタ全体のコンセンサスが中断されます。
3.PBFT
PBFT (Practical Byzantine Fault Tolerance) は、実用的なビザンチン フォールト トレランス システムです。
ビザンチン フォールト トレランスと比較すると、操作の複雑さが指数関数レベルから多項式レベルにまで軽減され、分散システムでビザンチン協定を適用できるようになります。
PBFT は、ノード アクセス メカニズムを必要とするプライベート チェーンまたはコンソーシアム チェーンに適していますが、PBFT はシビル攻撃を防ぐことができないため、パブリック チェーンには適していません。シビル攻撃はおそらく、悪意のあるユーザーが 51% に達するなど、全体的なコンセンサスに影響を与えるのに十分な数のアカウントを作成できることを意味します。
PBFT では、ノードの総数が 3f+1 の場合、コンセンサスを形成するために有効なノードの数は 2f+1 以上でなければなりません。つまり、エラーを許容するノードの数は最大で f です。たとえば、上記の 4 ノードの例のように、3f+1=4 でフォールト トレラント数 f=1 を計算すると、p2p ネットワークで切断されたノードの最大数は 1 であり、正常なノードの数は2f+1=3 未満であること。したがって、6 番目の図では p2p 接続を持つノードが 2 つしか残っておらず、コンセンサスを形成することはできません。
. ...- . .-. -.-- - .... .. -. --. .-- .. .-.. .-.. -... . --- -.-