編集者 | キャロル

編集者 | キャロル

「コントラクト内のチェーン上のデータの読み取り許可をどのように実現するか?」という質問がよくあります。

このような要求の背後にあるのは、開発者がチェーン上にデータを置き、ビジネス上の合意に達するためにスマート コントラクトにそれを管理および計算させたいと考えているが、チェーン上の他の権限のない参加者を避けるためにデータを公開したくないということです。それを読むことで情報が得られます。

最も直感的な実装アイデアは、コントラクト コードにフィルタリング ロジックを記述し、データの返されることを許可する前に呼び出し元が特定の条件 (ホワイトリストに含まれていることなど) を満たしていると判断し、そうでない場合はデータを拒否することです。

ケースを設定します: ポイント アライアンス チェーンがあり、チェーンの参加者にはアリス、ボブ、カール、デイブなどとその家族が含まれます。各人のポイント残高が次のように設定できることを望みます。自分自身とその家族には表示されますが、他の参加者には表示されません。

クライアントは、ブロックチェーンのアプリケーション レベルのインターフェイスを通じて特定のノードにリクエストを送信し、スマート コントラクトの get メソッドを呼び出してボブのポイントを確認します。スマート コントラクトは、不正アクセスを拒否する許可制御ロジックを作成します。

各ノードでのスマート コントラクトの実行ロジックは一貫しているため、リクエストがどのノードに送信されても​​、結果は同じになります。これは良い考えのように思えるかもしれませんが、実際はそうなのでしょうか？

結論を先に述べておきます。これは「永続的ではなく一時的な」アプローチであり、データが漏洩しないことを保証するものではありません。

今後は「多拠点・トラストレス」の考え方で本件を再検討していきます。

まず分析しましょう。データはどのようにチェーンに保存されているのでしょうか?どのような状況で漏洩するのでしょうか？

ブロックチェーン ネットワーク ノードは、さまざまな参加者の環境に分散されており、ブロックチェーンのデータ一貫性特性により、各ノードはデータの完全なコピーを保持します。データベースが LevelDB/RocksDB などのファイル タイプ データベースであるか、Mysql などのリレーショナル データベースであるかに関係なく、データは各ノードのデータベース インスタンスに分類されます。

つまり、ボブのポイント残高はすべてのノードのハードディスクに保存され、MySQL データベース ツールで表示すると次のようになります。

チェーン上に（低い確率で）ブロックチェーン技術にある程度の経験を持ち、密かに「悪意」を抱いている参加者（ビザンチンプレイヤーとも呼ばれます）がいる場合、その参加者はツールを使用してローカルデータベースを開き、ボブの残高を直接クエリできます。このようにして、データ漏洩を防ぐためにコントラクトを使用する制御ロジックは完全にバイパスされます。それはとても簡単です。

また、ブロックチェーンデータは契約書だけでなく、取引記録とも密接に関係しています。

トランザクションを送信するとき、トランザクション パラメータにはデータの一部またはすべてが含まれ (たとえば、アリスは 100 をボブに転送します)、トランザクションはブロックにパッケージ化され、最終的にノード データベースに書き込まれます。

ブロック データとトランザクション データのクエリは通常、コントラクト ロジックでは実装されないため、コントラクトにフィルタリング ロジックを記述するだけでは、これらのデータの読み取りを防ぐことはできません。ビザンチン プレーヤーは、ローカル データベース内のブロック データを走査し、トランザクション履歴の詳細を取得し、トランザクション フローを最初から最後まで再生して、ボブの現在の残高が 300 であることを知ることができます。

テクノロジー スタック全体の観点から見ると、ビザンチン プレーヤーがツールを使用してローカル データにアクセスし、ブロックを横断し、取引することは簡単であり、ブロックチェーン ネットワーク インターフェイス、プログラムの側面からブロックチェーン システムのコードを変更することもできます。メモリ、スマート コントラクト エンジン、プロトコル パッケージ、ブロック、トランザクション フロー、コントラクト コンテキスト、ステータス データなどからの平文データに割り込み、盗聴し、傍受します。データが暗号化されており、キーがノード所有者の手に渡っている場合でも、彼はまだロックを解除できます。

したがって、ブロックチェーンの基盤となるコードからデータの読み取り許可を制御することも無駄であり、結局のところ、オープンソースのコードは誰でも変更できます。中国の「悪者」は全能であり、防御するのが困難です。

結論として、ブロックチェーンが重視するのは、そしてそして"一貫性"平文データがチェーン上でブロードキャストされる限り、他人がそれを入手する方法は無数にあります。コントラクト層であっても、基礎となるコードであっても、ほぼすべての読み取り制御ロジックは次のようになります。窓紙つついて壊す、みたいなマジノ線同じでは駄目だ。

これを見て、データの読み取りがこれほど無防備であれば、ブロックチェーン上の「書き込み」権限はまだ意味があるのか​​、と疑問に思う人もいるかもしれません。答えは「はい」です。

ポイントの例に戻ると、アリスがポイントを転送するトランザクションを開始できるように、アリスをポイント管理者として設定し、ボブはアリスからのポイントのみを受け取ります。ポイント譲渡の取引はネットワーク全体の合意を経る必要があり、すべての合意ノードは契約書に書かれたルールをチェックし、要件を満たしていない場合は署名を拒否します。権限を超えた取引が合意できない場合は、データは変更されません。

このとき、たとえビザンチンノードの数が少なくても、ローカルノードがどんなに頑張ってもネットワーク全体のデータを改ざんすることはできません。

合意を追求してトランザクションを「書き込む」, そのため、クライアントがトランザクション (sendTransaction または sendRawTransaction) を送信するときは、デジタル署名する必要があり、ブロックチェーン システムは署名を検証して、どの外部アカウントがトランザクションを送信したかを確認します。これは厳密に検証され、正確に追跡できます。

「読み取り」操作は共有をより重視します、データを読み取る操作は実際にはコンセンサスプロセスを経ず、自分のノード上でデータをめくるだけです。通常、ブロックチェーンシステムでは読み取りインターフェース（呼び出し）に送信者を厳密に記入する必要がなく、デジタル署名も必要としないため、契約読み取り方法で外部アカウントを判断することは無効です。

上記の分析に基づいて、チェーンに読み取り制御を実装するのは簡単ではないと結論付けることができます。

読み取り制御ロジックに対する考慮が不十分な場合、テストと検証のために自分のノードでデータを読み取り、外観は問題ないように見えます。データはビザンチン プレーヤーによって反転されました。下が上です。

多者間のコラボレーションにおける信頼の喪失、およびデータ共有、オープン性、透明性の追求を考慮すると、一般的に、漏洩できない重要かつ機密データの場合は、慎重にチェーンにアップロードする必要があります。公約数」を共有することができます。

実際、多くのブロックチェーン システムでは、トランザクションと残高のステータスがネットワーク全体に表示されます。いわゆる匿名性やプライバシーは、平文のアカウントに代わる公開鍵と秘密鍵とアドレス システムのみを使用します。金融などの分野には適していません。モデルが複雑で包括的なプライバシーが重視される政府業務。

では、共有、透明性、オープン性を考慮しながらデータの可視性を適切に制御するには、他にどのような方法があるでしょうか?

最初のアイデアはオフチェーンガバナンスとの組み合わせ、責任と権利の境界について合意すること。ビジネス システム内でデータが漏洩しないように、またブロックチェーン アプリケーション層、表示インターフェイス、レポート、ログ、データベース、その他のリンクが漏洩しないように、契約およびインターフェイス レベルでのアクセス許可の設計と実装を適切に行いました。権限のない人によるアクセスを防止し、内部での IOperate リスクを排除します。

他人のノードについては、私は気にしません、それは他人の責任です、データを漏洩して悪用した人は厳しく罰せられます（実際に証拠を入手するのは非常に困難です）。この種のロジックは、実際には「みんなの前で雪を掃く」ことを意味します。このモードでは、私の機密データを他の人にアップロードすることはできません。

2つ目のアイデアは、暗号化の導入。以下にいくつかの例を示します。

非対称暗号化:チェーン上のデータは受信者の公開鍵で暗号化され、受信者だけが自分の秘密鍵でロックを解除できます。

パスワードエンベロープ:アップリンクデータは特定のパスワードで暗号化されており、そのパスワードはオフチェーンチャネルを通じて受信者に与えられ、パスワードを知っている受信者のみがそれを復号化できます。

プロパティの暗号化:データは属性暗号アルゴリズムを使用して暗号化されており、指定された属性（管理者属性など）を満たす人のみが復号できます。これらのソリューションを考慮すると、計算、送信、保存のオーバーヘッドが大きくなることに加え、暗号化されたデータは平文の計算をサポートしていないため、複雑なビジネス契約ロジックの実装が困難になります。また、たとえ暗号化されていても、基本的にデータのすべての情報は依然としてチェーン上にあることに注意する必要があり、時間の経過とともに、計算能力とアルゴリズム（量子暗号など）の進化が暴力によって解読される可能性があります。鍵が漏洩・推測されやすく、チェーン上のデータが取り出せなくなった場合、世界に公表される危険性があるため。

3つ目のアイデアは、概要のみがチェーンにアップロードされます、データの平文はチェーン上にまったくありません。

実際、ブロックチェーンの役割は、必ずしもデータを完全に把握して複雑なビジネスルールを実行することではなく、複数の証人の信頼性に依存してデータの正確性と完全性を検証し、証拠とトレーサビリティの役割を果たすことです。現段階では、多くのブロックチェーン システムは主にそのようなロジックに基づいており、客観的に信頼のアンカー ポイントとして機能します。

平文データが必要な場合は、サマリー内のアドレス情報を介してオフチェーンシステムにアクセスし、きめ細かな権限制御が行われ、チェーン上のサマリーとの相互検証が行われます。外。

しかし、データがチェーン上にないということはまだ少し理解できませんが、このようなブロックチェーンの革新的な概念とスマートコントラクトの強力な機能をどのように最大限に活用できるのでしょうか?

それはプライバシー コンピューティングゼロ知識証明、準同型暗号化、セキュアなマルチパーティ コンピューティング、フェデレーテッド ラーニングを含む一連の重火器は、加算、減算、乗算、除算、論理演算、ソート、統計分析を実行でき、さらに次のことを達成できます。法規制遵守要件を満たすための「匿名のフロントデスクと監査可能な経歴」の効果。これがブロックチェーンにおける「目に見えない利用可能」の究極の意味です。

スペースの制限により、ここではプライバシー計算の詳細については説明しません。WeDPR プライバシー保護に関連するオープン ソース シナリオ ソリューション、特に、問題を解決するために使用できる VCL ブロックチェーン検証可能な暗号文台帳などのいくつかのシナリオを参照できます。上記の点に加えて、プライバシーの問題もいくつかあります。

WeDPR プライバシー保護関連のオープンソース シナリオ ソリューション:

https://fintech.webank.com/wedpr/VCL

エピローグhttps://sandbox.webank.com/wedpr/confidentialpayment/#/start

エピローグ

元々は「コントラクトの読み取り権限をどう書くか」というような小さな問題について話したかっただけですが、長い記事になってしまいました。

実際、ブロックチェーンのプログラミングと開発に直面するとき、スタンドアロン ソフトウェアやクラスター ソフトウェアの作成などの問題について考えることはできませんが、共有の基本理念に基づいて、多者参加とトラストレスな環境での協力関係を十分に考慮する必要があります。まず、プライバシー保護の訴えに注意を払い、データの重要性と機密性を比較検討し、次に技術スタックを深く掘り下げ、さまざまなアルゴリズムの有効性とコストを考慮し、現在および将来のリスクと利点を組み合わせて、データとプライバシーを完全に保護し、ビジネスを安全に発展させ、自社とユーザーの権利と利益を保護するために、適切な戦略を選択します。