ホイールセットの分散レジストリ: Hyperledger Fabric のエクスペリエンス

こんにちは、私は DRD KP プロジェクト (ホイール セットのライフ サイクルを監視するための分散データ レジストリ) のチームで働いています。 ここでは、テクノロジーの制約の下でこのプロジェクトのエンタープライズ ブロックチェーンを開発した私たちのチームの経験を共有したいと思います。 主に Hyperledger Fabric について説明しますが、ここで説明するアプローチは、あらゆる許可型ブロックチェーンに適用できます。 私たちの研究の最終目標は、最終製品が使いやすく、メンテナンスがそれほど難しくないように、エンタープライズ ブロックチェーン ソリューションを準備することです。

ここでは発見や予期せぬ解決策、そしてユニークな展開が強調されることはありません（私には何もないので）。 私は自分のささやかな経験を共有し、「それは可能だった」ことを示したいだけです。そして、おそらく、コメントで他の人の良い決断やあまり良くない決断を下した経験について読みたいだけです。

問題: ブロックチェーンはまだ拡張できません

現在、多くの開発者の努力は、ブロックチェーンを美しいラッパーの時限爆弾ではなく、真に便利なテクノロジーにすることを目的としています。 ステートチャネル、オプティミスティックロールアップ、プラズマ、シャーディングはおそらく一般的になるでしょう。 いつか。 あるいは、TON は再び打ち上げを XNUMX か月延期し、次のプラズマグループは消滅するかもしれません。 私たちは次のロードマップを信じて、夜に素晴らしいホワイトペーパーを読むことはできますが、今ここで、私たちが持っているもので何かをする必要があります。 やっちまえ。

現在のプロジェクトで私たちのチームに設定されたタスクは、一般的に次のようになります。信頼関係を構築したくない被験者は数千人に上ります。 特別なパフォーマンス要件を必要とせずに通常の PC で動作し、集中会計システムと同等のユーザー エクスペリエンスを提供するソリューションを DLT 上に構築する必要があります。 ソリューションの背後にあるテクノロジーは、悪意のあるデータ操作の可能性を最小限に抑える必要があります。だからこそ、ブロックチェーンが登場します。

ホワイトペーパーやメディアのスローガンは、次の開発では XNUMX 秒あたり数百万件のトランザクションが可能になると約束しています。 本当のところは何でしょうか？

メインネット イーサリアムは現在、約 30 tps で実行されています。 これだけでは、企業のニーズに適した形でブロックチェーンとして認識することは困難です。 許可されたソリューションの中には、2000 tps を示すベンチマークがあります (Quorum) または 3000 tps (ハイパージーガーファブリック、出版物には少し少ないですが、ベンチマークが古いコンセンサス エンジンで実行されたことを考慮する必要があります)。 だった 革新的な生地加工の試み、20000 tpsという最悪の結果ではありませんでしたが、今のところこれは単なる学術研究であり、安定した実装が待たれます。 ブロックチェーン開発者の部門を維持する余裕のある企業がそのような指標に我慢する可能性は低いでしょう。 しかし、問題はスループットだけではなく、遅延もあります。

レイテンシ

トランザクションが開始されてからシステムによる最終承認までの遅延は、メッセージが検証と順序付けのすべての段階を通過する速度だけでなく、ブロック形成パラメータにも依存します。 たとえ私たちのブロックチェーンが 1000000 tps の速度でコミットできるとしても、10 MB のブロックを生成するのに 488 分かかるとしても、それは簡単になるでしょうか?

Hyperledger Fabric のトランザクション ライフサイクルを詳しく見て、時間がどこに費やされ、それがブロック生成パラメーターにどのように関連しているかを理解しましょう。

ここから取られた: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) クライアントはトランザクションを作成し、それを承認ピアに送信します。後者はトランザクションをシミュレートし (チェーンコードによって行われた変更を現在の状態に適用しますが、台帳にはコミットしません)、RWSet (キー名、バージョン、および値) を受け取ります。 CouchDB のコレクションから取得され、( 2) エンドーサーは署名された RWSet をクライアントに送り返します。(3) クライアントは、必要なすべてのピア (エンドーサー) の署名の存在を確認してから、トランザクションを順序付けサービスに送信します。 、または検証なしで送信する場合 (チェックは後で行われます)、順序付けサービスはブロックを形成し、( 4) エンドーサーだけでなくすべてのピアに送り返します。 ピアは、読み取りセット内の鍵のバージョンがデータベース内のバージョンと一致すること、すべてのエンドーサーが署名を持っていることを確認し、最後にブロックをコミットします。

しかし、それだけではありません。 「順序付け者がブロックを形成する」という言葉は、トランザクションの順序だけでなく、リーダーからフォロワーへ、そしてその逆への 3 つの連続したネットワーク リクエストも隠します。リーダーはメッセージをログに追加し、フォロワーに送信し、後者はそれを追加します。ログにレプリケーション成功の確認を送信し、リーダーがメッセージをコミットし、フォロワーにコミット確認を送信し、フォロワーがコミットします。 ブロック形成のサイズと時間が小さいほど、注文サービスがコンセンサスを確立する必要がある頻度が高くなります。。 Hyperledger Fabric には、ブロック形成のための XNUMX つのパラメータがあります。BatchTimeout - ブロック形成時間と BatchSize - ブロック サイズ (トランザクションの数とブロック自体のバイト単位のサイズ)。 いずれかのパラメータが制限に達すると、すぐに新しいブロックが解放されます。 順序ノードが多いほど、これにかかる時間が長くなります。 したがって、BatchTimeout と BatchSize を増やす必要があります。 ただし、RWSet はバージョン管理されているため、作成するブロックが大きくなるほど、MVCC 競合が発生する可能性が高くなります。 さらに、BatchTimeout が増加すると、UX が壊滅的に低下します。 これらの問題を解決するための次のスキームは、私にとって合理的で明白であるように思えます。

ブロックのファイナライズを待たずにトランザクションのステータスを追跡できるようにする方法

形成時間とブロック サイズが長いほど、ブロックチェーンのスループットは高くなります。 一方が他方から直接続くわけではありませんが、RAFT でコンセンサスを確立するには、リーダーからフォロワーへ、そしてそのリーダーからフォロワーへの XNUMX つのネットワーク リクエストが必要であることを覚えておく必要があります。 順序ノードが多いほど、これにかかる時間が長くなります。 ブロック形成のサイズと時間が小さいほど、そのような相互作用が多くなります。 エンドユーザーのシステム応答時間を増加させずに、生成時間とブロックサイズを増やすにはどうすればよいでしょうか?

まず、同じバージョンの異なる RWSet が含まれる可能性がある、大きなブロック サイズによって引き起こされる MVCC 競合を何らかの方法で解決する必要があります。 明らかに、クライアント側 (ブロックチェーン ネットワークに関して言えば、これはバックエンドである可能性があり、それがバックエンドである可能性があります) では、次のことが必要です。 MVCC 競合ハンドラー、別のサービス、または再試行ロジックを使用してトランザクションを開始する呼び出しの上の通常のデコレーターのいずれかにすることができます。

再試行は指数関数的な戦略で実装できますが、レイテンシも同様に指数関数的に低下します。 したがって、特定の小さな制限内でランダムな再試行を使用するか、一定の再試行を使用する必要があります。 最初のオプションでは衝突の可能性を考慮して。

次のステップでは、クライアントとシステムの対話を非同期にして、15、30、または 10000000 秒待機しないようにします。これを BatchTimeout として設定します。 しかし同時に、トランザクションによって開始された変更がブロックチェーンに記録されているかどうかを検証する機能を維持する必要があります。
データベースを使用してトランザクションのステータスを保存できます。 最も簡単なオプションは、使いやすさの点で CouchDB です。データベースにはすぐに使用できる UI と REST API があり、レプリケーションとシャーディングを簡単に設定できます。 同じ CouchDB インスタンス内に、Fabric を使用して世界の状態を保存する別のコレクションを作成するだけです。 このような種類の文書を保管する必要があります。

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

このドキュメントは、トランザクションがピアに送信される前にデータベースに書き込まれ、作成操作の場合はエンティティ ID がユーザーに返されます (同じ ID がキーとして使用されます)。その後、ステータス、TxID、およびエラー フィールドが関連情報がピアから受信されると更新されます。

このスキームでは、ユーザーはブロックが最終的に形成されるのを待たずに、画面上の回転ホイールを 10 秒間見ながら、システムから即座に応答を受け取り、作業を続けます。

メモリを節約する必要があり、特にこのやり取りがプレーン テキスト プロトコルを使用して行われる場合、別のデータベース サーバーとのネットワーク インタラクションに時間を無駄にしたくないため、トランザクション ステータスの保存に BoltDB を選択しました。 ちなみに、CouchDB を使用して上記のスキームを実装する場合でも、単に世界の状態を保存する場合でも、いずれの場合でも、CouchDB にデータを保存する方法を最適化することは意味があります。 CouchDB のデフォルトでは、B ツリー ノードのサイズは 1279 バイトで、これはディスク上のセクター サイズよりもはるかに小さいため、ツリーの読み取りとリバランスの両方でディスクへの物理アクセスがより多く必要になります。 最適なサイズは標準に対応します 高度なフォーマット 4キロバイトです。 最適化するにはパラメータを設定する必要があります btree_chunk_size が 4096 に等しい CouchDB 構成ファイル内。 BoltDB の場合、このような手動介入 不要.

バックプレッシャー: バッファー戦略

しかし、そこにはたくさんのメッセージが含まれている可能性があります。 システムが処理できる以上のリソースを、図に示されているサービス以外にも多数の他のサービスと共有します。これらすべては、Intellij Idea の実行が非常に面倒なマシン上でも問題なく動作するはずです。

通信システム、プロデューサーとコンシューマーの容量が異なるという問題は、さまざまな方法で解決されます。 何ができるか見てみましょう。

落ちる: T 秒間で最大 X 個のトランザクションを処理できると主張できます。 この制限を超えるリクエストはすべて破棄されます。 これは非常にシンプルですが、UX のことは忘れても大丈夫です。

制御: コンシューマは、負荷に応じてプロデューサの TPS を制御できる、ある種のインターフェイスを持っている必要があります。 それは悪くありませんが、負荷を作成するクライアントの開発者にこのインターフェイスを実装する義務が課せられます。 ブロックチェーンは将来、多くの古くから存在するシステムに統合されることになるため、これは私たちにとって受け入れがたいことです。

バッファリング: 入力データ ストリームに抵抗する代わりに、このストリームをバッファリングし、必要な速度で処理できます。 優れたユーザー エクスペリエンスを提供したい場合、これが最適なソリューションであることは明らかです。 RabbitMQ のキューを使用してバッファを実装しました。

1 つの新しいアクションがスキームに追加されました。(2) API へのリクエストが到着した後、トランザクションを呼び出すために必要なパラメーターを含むメッセージがキューに配置され、クライアントはトランザクションが受け入れられたことを示すメッセージを受け取ります。システム、(XNUMX) バックエンドは、設定で指定された速度でキューからデータを読み取ります。 トランザクションを開始し、ステータス ストア内のデータを更新します。
これで、形成時間とブロック容量を好きなだけ増やして、遅延をユーザーから隠すことができます。

その他のツール

原則としてチェーンコードには最適化するものが何もないため、ここではチェーンコードについては何も述べられていません。 チェーンコードは可能な限りシンプルかつ安全でなければなりません。必要なのはそれだけです。 このフレームワークは、チェーンコードを簡単かつ安全に作成するのに役立ちます CCKit S7 Techlab と静的アナライザーから 復活^CC.

さらに、私たちのチームは、Fabric の操作を簡単かつ楽しくするための一連のユーティリティを開発しています。 ブロックチェーンエクスプローラー、のためのユーティリティ ネットワーク構成の自動変更 (組織の追加/削除、RAFT ノード)、ユーティリティ 証明書の失効とアイデンティティの削除。 貢献したい方は大歓迎です。

まとめ

このアプローチにより、Hyperledger Fabric を Quorum、他のプライベート Ethereum ネットワーク (PoA または PoW) に簡単に置き換えることができ、実際のスループットは大幅に低下しますが、同時に通常の UX (ブラウザーのユーザーと統合システムの両方) を維持できます。 スキーム内のファブリックをイーサリアムに置き換える場合、再試行サービス/デコレーターのロジックを MVCC 競合の処理からアトミックなノンス増分と再送信に変更するだけで済みます。 バッファリングとステータス ストレージにより、応答時間をブロック形成時間から切り離すことが可能になりました。 これで、何千もの順序ノードを追加できるようになり、ブロックが頻繁に形成されて順序付けサービスが読み込まれることを心配する必要がなくなります。

基本的に、私が共有したかったのはこれだけです。 誰かの仕事の参考になれば嬉しいです。

出所： habr.com