石翔𞓜微大衆銀行ブロックチェーンの核心開発者
ブロックチェーンの中で、チェーン上の各参加者はブロックチェーンの共通認識メカニズムによって信頼システムを構築する。問題が来ました。複数のブロックチェーンのチェーンにまたがる場面で、チェーンとチェーン間の信頼はどうやって伝えられますか?信じること、信じることは何ですか?このようなチェーンをまたいで信頼して、またどのように創立するべきですか?
1.チェーン間の信頼、手紙の内容は何ですか?結論を先に述べます。チェーン間の信頼は、チェーンの実行メカニズムを信頼することを前提として、信頼は実行メカニズムの実行結果に合致しています。その理由は、チェーンをまたぐ基礎操作から話さなければなりません。トランジットチェーンの基礎操作は、相手のチェーンがある操作を実行した後、ローカルチェーンが他の操作を実行することができます。ブロックチェーンAがX操作に成功した後、ブロックチェーンBが操作Yを実行します。X操作はY操作実行の前提条件です。トレイ上記の操作において、一つの要求Xは署名を経て、取引をブロックチェーンAに送り、ブロックチェーンAのコンセンサスを経てブロックを生成する。ブロックにはブロック、取引リストなどの情報が含まれています。ブロックの中には共通の結果情報が含まれています。上記の情報をブロックチェーンと総称して実行した結果、具体的な流れは下図のようになります。トレイブロックチェーンAの実行結果がブロックチェーンBに送られます。ブロックチェーンBは、実行要求Yの前に、まずXがチェーンされているかどうかを判断しなければならない。
判断の方法は、ブロックチェーンBの運転環境においてブロックチェーンAがXに関する実行結果が有効かどうかを検証することである。検証により、Xがチェーンアップされたことを示し、ブロックチェーンBは、後続のステップを実行し続けることができる。送信要求Yは、ブロックチェーンBにチェーンアップする。
この動作は、ブロックチェーンBがブロックチェーンAの実行機構を信頼しなければならないという前提に基づいていることに留意されたい。ブロックチェーンA上の正確な実行結果は、ブロックチェーンA上の各当事者の意思を表しています。ブロックチェーンBはブロックチェーンA上のある取引が有効かどうかを検証するために、ブロックチェーンAの実行メカニズムを信頼し、ブロックチェーンAの実行メカニズムに従って、ブロックチェーンAの実行結果を検証してこそ、ブロックチェーンA上のある取引がチェーンアップされたと判断できる。
全体のプロセスにおいて、チェーンの実行結果を検証することによって、要求がチェーン上にあるかどうかを判断することは、チェーン間の信頼を確立するためのコアステップであることが分かる。したがって、チェーン間の信頼は、チェーンの実行メカニズムを信頼することを前提として、信頼は、実行メカニズムの実行結果と一致する。
チェーン間信頼を確立するには、4つの層の検証を経て実行結果が異なるブロックチェーンで異なる実装方式がありますが、万変はその宗派から離れず、ブロックチェーンの核心データ構造はブロック単位のチェーン構造であり、取引はブロック内に存在します。
したがって、実行結果の検証を以下の4つに分けることができます。トレイ検査ブロック連続:検証開始時に、データソースを確認し、ブロックチェーンの連続性に基づいて、ブロックが指定ブロックチェーンに属するかどうかを検証し、攻撃者が任意のブロックチェーンのブロックで偽造することを防止する。
ピース共通認識:ソースを確認した後、ブロックがチェーン全体の意思を表しているかどうかを検証する必要があります。このステップはブロックの共通情報が要求に合致しているかどうかを検証し、攻撃者が共通認識を経ていないブロックで偽造することを防止する。
取引の存在:ブロックが合法的に検証された後、指定された取引がこのブロックに属するかどうかを検証する必要があります。異なるチェーンには異なる検証方法があり、次のセクションで説明します。
取引の正確さ:取引の存在性が検証された後、この取引を代表することはできません。確かにチェーンシーンをまたいで予想される操作です。業務シーンに合わせて、取引の具体的な内容が予想に合っているかどうかを判断します。
上記4階を通過してこそ、検証が通過します。検証が通過したら、説明操作はすでに相手のチェーンにチェーンしています。ローカルチェーンは、後続のステップを実行することができる。
各階層の検証メカニズムの実施形態において、前記4層の検証は、異なるブロックチェーン上で異なる実施形態がある。WeCrossのプラグイン化フレームワークは、汎用的なプログラミングインターフェースを定義し、開発者はチェーンタイプに従って4つのレベルの検証ロジックを実現すればいいです。
以下、各階層の具体的な実現案を見てみます。
検査ブロック連続
異なるブロックチェーン上の大同小異を実現する。現在のブロックには前のブロックのハッシュ値が記録されており、現在のブロックのハッシュ値はまた次のブロックに記録され、複数のブロックは順次接続されてブロックチェーンを形成する。異なるブロックチェーンは、ハッシュアルゴリズムとブロック・ハッシュを計算するフィールドにのみ差異がある。
WeCrossでブロックチェーンの連続性を検証し、写真対応チェーンの実現によって、ブロックを順次チェーンに接続して検証すればいいです。
検査ブロックコンセンサス
ブロック共通認識、すなわちブロックの共通認識情報が対応するアルゴリズム条件に合致するかどうかを検証する。異なるアルゴリズムは異なる実装がある。ここでは、最も代表的な2つのコンセンサスアルゴリズムを提供する。POW(作業量証明)とPBFT(実用的なビザンチンフォールト)。
POW最終一致の共通アルゴリズムに属しており、最長の鎖と遅延確認により徐々に共通認識の結果を収束させていく。WeCrossはPOW検証に必要なステップを提供しています。
検査難度:ブロックのnonceが作業量証明条件
満たしているかどうかを検証します。ディレイ:現在のブロックが既知の最高ブロックNブロックより低いかどうかを検証します。鎖で悪事を働く
PBFTアルゴリズムは多面的な合意の後、直ちに合意に達しました。ブロックチェーンフォークとロールバックは存在しません。アルゴリズムでは、ノードは複数の相互ブロードキャスト署名によって共通認識を達成する。
ブロックの中で、十分な数量の署名はブロックの合法性を表しています。したがって、WeCrossではPBFTに対する検証が簡単である:
公開鍵を配置する:チェーンコンセンサスノードの公開鍵
事前に配置し、署名を確認する:事前に配置された公開鍵でブロックに署名の有効性を検証し、有効署名数がPBFTコンセンサス条件
達するかどうかを判断する。トレーダーが存在するのと同様に、異なる点から判断を行う必要があり、代表的なSPである。V(簡単な支払い検証)と裏書ポリシー。
SPV軽いクライアントを実現するために、現在はほとんどのブロックチェーンで実現されています。この技術は、トランスチェーン技術が発達するにつれて、ブロック内のあるデータの存在を検証するためにも使用される。
取引を例にして、ブロックヘッダに記録されています。現在のブロック内のすべての取引ハッシュは、Merkleツリーのツリー根、すなわち「取引ルート」を構成する。いずれの取引も、唯一の取引ルートへのMerkle pathに対応しています。ブロック内に存在しない取引は、取引ルートへのMerkle Pathを偽造することができません。したがって、WeCrossではある取引のMerkle Pathを検証するだけで、ある取引があるブロックに属するかどうかを判断することができます。
裏書ポリシーはHyperledger Fabricに採用されています。Fabricでは、各取引は事前に定義された裏書ポリシーを満たす必要があります。
トランザクションは実行時に複数のバックライトノードに署名され、各当事者が署名して裏書きポリシーを満たしている場合にこそ、この取引は有効とされる。Fabricは、バックライトノード署名情報を取引の一部としてブロックに保存する。複数の取引で構成されるブロック内の取引リスト。取引リストは、ハッシュ値をバイナリ形式で計算し、このハッシュ値はブロックヘッダに記録される。したがって、WeCrossの現在の実装においては、取引が取引リストにあるかどうかを判断し(かつ、対応するフラグが有効)、取引リストのハッシュ値をチェックするだけで、取引の存在を初期的に判断することができる。
WeCrossその後、裏書ポリシーに関連して、取引の裏書ノード署名を検証し、取引の存在検証の有効性をさらに高める。
トランザクションが正確である
取引が正確であるかどうかは、トラフィックの予期されるパラメータに基づいて、最初の3段階で検証された取引ハッシュ(またはバイナリ)が、トラフィックが予想されるその動作であるかどうかを判断することである。
.例えば、
er(a,b,100)と期待される場合、対応する取引内容はget(a)ではない。検証するには、取引の符号化方式とハッシュ・アルゴリズムに従って、トラフィック予想パラメータとトランザクション・ハッシュを検証する必要がある。またはバイナリ)は対応していますか?異なるブロックチェーン実装の違いは、取引符号化とハッシュアルゴリズムにのみ反映され、チェーン実装に従って、対応する方法を用いて検証すればよい。
WeCrossの異なるチェーンのプラグインは、異なる検証ロジックを実装します。FISCO BOSプラグインは、RLP符号化とSHA-256のハッシュアルゴリズムを用いて、取引のハッシュが正しいかどうかを検証するものであり、ファブリックプラグインはProttoBuf符号化を用いて、取引のバイナリが正しいかどうかを検証するものである。
完全検証プロセスは、例えばより直感的に説明するために、FISCO BOSの完全検証プロセスを以下の図に示す。トレイあるチェーンがチェーンの実行結果を得たら、現地で検証できます。
検証ブロック連続では、FISCO BOSは、ブロックヘッダのうちの親ブロックに対してハッシュを介してリアルな親ブロックとハッシュし、検証する。このブロックは対方鎖のブロックです。
検証ブロックのコンセンサスにおいて、現在のブロックの署名リストを検証することにより、合法的な署名数がPBFTコンセンサス条件を満たしているかどうかを判断し、現在のブロックがチェーン全体の意思を表していることを確認する。
取引のハッシュが取引のルートに向かうMerkle Pathの正確性を検証することによって、取引がブロックチェーン上に既に存在していると判断することができる。
取引の予想、取引のバイナリ、取引のハッシュの対応関係を検証することによって、取引がトラフィックの予期されるその動作であると判断することができる。4つのレベルの検証が通過した後、業務が予想される操作は相手のチェーンにチェーンして、検証が完了したことを説明します。
チェーン間の信頼を総括し、チェーンの実行メカニズムを信頼することを前提として、手紙は実行メカニズムに適合した実行結果である。実行結果が正しいかどうか、検証したのは4つのレベルのデータです。検証メカニズムは異なるチェーンで異なる実装があり、WeCrossはプラグイン化されています。サポートを提供します。
現在WeCrossはFISCO BOSとHyperledger Fabricの相互認識を実現しました。もっと多くのブロックチェーンプラットフォームのアクセス方案は熱い討論の中で、参加を歓迎して、チェーンを跨ぐインフラの発展を共に推進します。train.