ブロックチェーンにコードを配置する方法は複数あります
ブロックチェーンに関するほとんどの議論では、「スマートコントラクト」の概念が登場するまでにそれほど時間はかかりません。 一般的な想像では、スマートコントラクトは、信頼できる仲介者を必要とせずに、パーティ間の対話の実行を自動化します。 法的な関係を言葉ではなくコードで表現することで、意図的かどうかに関係なく、エラーを発生させずに直接トランザクションを実行できるようになります。
技術的な観点から見ると、スマート コントラクトはより具体的なものです。つまり、ブロックチェーン上に存在し、そのチェーンのトランザクションのルールを定義するコンピューター コードです。 この説明は非常に単純に聞こえますが、その背後には、これらのルールがどのように表現、実行、および検証されるかという大きな違いがあります。 新しいアプリケーションのブロックチェーン プラットフォームを選択するとき、「このプラットフォームはスマート コントラクトをサポートしていますか?」という質問があります。 尋ねるのは適切ではありません。 代わりに、「このプラットフォームはどのタイプのスマート コントラクトをサポートしていますか?」と尋ねる必要があります。
この記事の私の目標は、スマートコントラクトアプローチとそれが表すトレードオフの主な違いのいくつかを調べることです。 これを行うには、何らかの形のカスタマイズされたオンチェーンコードをサポートするXNUMXつの人気のあるエンタープライズブロックチェーンプラットフォームを調べます。 まず、IBMの ハイパージーガーファブリック、その契約を「チェーンコード」と呼びます。 XNUMXつ目は、マルチチェーンプラットフォームです。 スマートフィルター バージョン2.0で。 第三、 Ethereum （そしてその許可 Quorum & バロー スピンオフ）、「スマートコントラクト」の名称を広めました。 そして最後に、 R3 Corda、そのトランザクションで「契約」を参照します。 異なる用語のすべてにかかわらず、最終的にはこれらすべてが同じもの、つまりチェーンのルールを定義するアプリケーション固有のコードを指します。
先に進む前に、以下の内容の多くは本質的に技術的であり、一般的なプログラミングとデータベースの概念にある程度精通していることを前提としています。 良くも悪くも、これを回避することはできません。詳細に踏み込まないと、特定のプロジェクトでブロックチェーンを使用するかどうか、および（使用する場合）使用する適切なタイプのブロックチェーンについて、情報に基づいた決定を下すことは不可能です。
ブロックチェーンの基本
いくつかのコンテキストから始めましょう。 基礎となるデータベースに基づいて、複数の組織で共有されるアプリケーションを想像してみてください。 従来の集中型アーキテクチャでは、このデータベースは単一のパーティによってホストおよび管理され、参加者全員が信頼していなくても、すべての参加者が信頼しています。 データベースを変更するトランザクションは、多くの場合参加者から受信したメッセージに応答して、この中央パーティのシステム上のアプリケーションによってのみ開始されます。 アプリケーションは、意味のあるトランザクションのみを送信するように暗黙的に信頼されているため、データベースは単に指示された内容を実行します。
ブロックチェーンは、信頼できる仲介者なしで、共有データベースを管理する代替方法を提供します。 ブロックチェーンでは、各参加者がデータベースのコピーを保持する「ノード」を実行し、それを変更するトランザクションを個別に処理します。 参加者は、公開鍵または「アドレス」を使用して識別されます。各公開鍵には、ID所有者だけが知っている対応する秘密鍵があります。 トランザクションはどのノードでも作成できますが、トランザクションの起点を証明するために、開始者の秘密鍵によって「デジタル署名」されています。
ノードはピアツーピア方式で相互に接続し、トランザクションと、ネットワーク全体でタイムスタンプと確認が行われる「ブロック」を迅速に伝播します。 ブロックチェーン自体は、文字通りこれらのブロックのチェーンであり、すべての履歴トランザクションの順序付けられたログを形成します。 「コンセンサスアルゴリズム」は、集中管理を必要とせずに、すべてのノードがブロックチェーンの内容について合意に達することを保証するために使用されます。 （この説明の一部はCordaに適用されないことに注意してください。各ノードにはデータベースの部分的なコピーのみがあり、グローバルブロックチェーンはありません。これについては後で詳しく説明します。）
原則として、共有データベースアプリケーションは、コアでブロックチェーンを使用して設計できます。 しかし、そうすることは、集中シナリオでは存在しない多くの技術的課題を生み出します。
- 取引ルール。 参加者がデータベースを直接変更できる場合、どのようにしてアプリケーションのルールに従うようにしますか？ XNUMX人のユーザーがデータベースのコンテンツを利己的な方法で破損するのを阻止するものは何ですか？
- 決定論。 これらのルールが定義されると、データベースの独自のコピーのトランザクションを処理するときに、複数のノードによって複数回適用されます。 すべてのノードがまったく同じ結果を得られるようにするにはどうすればよいですか？
- 紛争予防。 中心的な調整がなければ、それぞれがアプリケーションのルールに従うXNUMXつのトランザクションをどのように処理しますが、それでも互いに競合しますか？ 競合は、システムを故意にゲームしようとしたり、不運やタイミングによる無実の結果である可能性があります。
では、スマートコントラクト、スマートフィルター、チェーンコードはどこにあるのでしょうか。 それらの主な目的は、これらの課題を解決するためにブロックチェーンの基盤となるインフラストラクチャと連携することです。 スマートコントラクトは、分散されたアプリケーションコードに相当します。中央のXNUMXつの場所で実行するのではなく、ブロックチェーンの複数のノードで実行し、データベースのコンテンツを変更するトランザクションを作成または検証します。
これらの課題の最初のトランザクションルールから始めて、それらがファブリック、マルチチェーン、イーサリアム、およびコーダでそれぞれどのように表現されるかを見てみましょう。
取引ルール
トランザクションルールは、ブロックチェーンを使用したデータベースで特定の機能を実行します。 変換 そのデータベースの状態で実行できます。 ブロックチェーンのトランザクションはその参加者のいずれかによって開始でき、これらの参加者はデータベースを自由に変更できるほど相互に信頼していないため、これが必要です。
トランザクションルールが必要な理由のXNUMXつの例を見てみましょう。 最初に、参加者によって公開されたPDFドキュメントを集約してタイムスタンプを付けるように設計されたブロックチェーンを想像してください。 この場合、ドキュメントを削除または変更する権利を誰も持つべきではありません。削除すると、システムの目的全体、つまりドキュメントの永続性が損なわれるためです。 次に、ユーザーの残高を追跡する共有の財務台帳を表すブロックチェーンを検討します。 参加者が自分の残高を勝手に膨らませたり、他人のお金を奪ったりすることはできません。
入力と出力
当社のブロックチェーンプラットフォームは、トランザクションルールを表現するためにXNUMXつの広範なアプローチに依存しています。 XNUMXつ目は「入出力モデル」と呼ばれ、MultiChainとCordaで使用されています。 ここで、トランザクションは、削除および作成するデータベース行または「状態」を明示的にリストし、それぞれ「入力」および「出力」のセットを形成します。 行の変更は、その行を削除し、その場所に新しい行を作成することと同等の操作として表されます。
データベース行は入力でのみ削除され、出力でのみ作成されるため、すべての入力は前のトランザクションの出力を「費やす」必要があります。 データベースの現在の状態は、「未使用のトランザクション出力」または「UTXO」のセット、つまり、まだ使用されていない以前のトランザクションからの出力として定義されます。 トランザクションには、「メタデータ」、「コマンド」、または「添付ファイル」と呼ばれる追加情報が含まれる場合があります。これらは、データベースの一部にはなりませんが、それらの意味や目的を定義するのに役立ちます。
これらのXNUMXつの入力、出力、メタデータのセットを考えると、MultiChainまたはCordaでのトランザクションの有効性は、これらのセットに対して任意の計算を実行できるコードによって定義されます。 このコードは、トランザクションを検証するか、対応する説明を含むエラーを返すことができます。 入出力モデルは、トランザクションがすべてのルールに従うことを保証するチェックリストを保持する自動化された「インスペクター」と考えることができます。 トランザクションがこれらのチェックのいずれかに失敗した場合、ネットワーク内のすべてのノードによって自動的に拒否されます。
入出力モデルを共有しているにも関わらず、MultiChainとCordaは非常に異なる方法で実装していることに注意してください。 MultiChainでは、出力に、JSON、テキスト、またはバイナリ形式のアセットやデータを含めることができます。 ルールは「トランザクションフィルター」または「ストリームフィルター」で定義され、すべてのトランザクション、または特定のアセットまたはデータのグループに関連するトランザクションのみをチェックするように設定できます。 対照的に、Corda出力の「状態」は、JavaまたはKotlinプログラミング言語のオブジェクトによって表され、データフィールドが定義されています。 Cordaのルールは特定の州に付属する「契約」で定義されており、州の契約はその状態を入力または出力に含むトランザクションにのみ適用されます。 これはCordaの 珍しい可視性モデル取引は、取引相手またはその後の取引が影響を与える取引先のみが見ることができます。
契約とメッセージ
私が「契約メッセージモデル」と呼ぶXNUMX番目のアプローチは、Hyperledger FabricとEthereumで使用されています。 ここでは、複数の「スマートコントラクト」または「チェーンコード」をブロックチェーン上に作成でき、それぞれに独自のデータベースと関連コードがあります。 契約のデータベースは、ブロックチェーントランザクションで直接変更するのではなく、コードでのみ変更できます。 この設計パターンは、オブジェクト指向プログラミングにおけるコードとデータの「カプセル化」に似ています。
このモデルでは、ブロックチェーントランザクションは、いくつかのオプションのパラメーターまたはデータとともに、コントラクトに送信されるメッセージとして始まります。 コントラクトのコードはメッセージとパラメーターに反応して実行され、その反応の一部として独自のデータベースを自由に読み書きできます。 コントラクトは他のコントラクトにメッセージを送信することもできますが、お互いのデータベースに直接アクセスすることはできません。 リレーショナルデータベースの言語では、契約は 施行された 「ストアドプロシージャ」。データベースへのすべてのアクセスは、事前定義されたコードを介して行われます。
イーサリアムのバリエーションであるファブリックとクォーラムはどちらも、ネットワークが複数の「チャネル」または「プライベートステート」を定義できるようにすることで、この状況を複雑にしています。 目的は、それぞれが特定のサブグループの参加者にのみ見える個別の環境を作成することにより、ブロックチェーンの機密性の問題を軽減することです。 これは理論的には有望に聞こえますが、実際には、各チャネルまたはプライベートステートのコントラクトとデータは、他のコントラクトとそれらから分離されています。 その結果、スマートコントラクトに関しては、これらの環境は個別のブロックチェーンに相当します。
ルールの例
これらXNUMXつのモデルを使用して、単一資産の財務台帳のトランザクションルールを実装する方法を見てみましょう。 元帳のデータベースの各行にはXNUMXつの列があり、所有者の住所と所有されている資産の数量が含まれています。 入出力モデルでは、トランザクションは次のXNUMXつの条件を満たす必要があります。
- トランザクションの出力の資産の合計数量は、入力の合計と一致する必要があります。 これにより、ユーザーが勝手にお金を作成または削除することを防ぎます。
- すべてのトランザクションは、その各入力の所有者によって署名される必要があります。 これにより、ユーザーが無断でお互いのお金を使うことができなくなります。
まとめると、これらXNUMXつの条件は、シンプルだが実行可能な金融システムを作成するために必要なすべてです。
契約メッセージモデルでは、資産の契約は「支払いの送信」メッセージをサポートします。このメッセージは、送信者のアドレス、受信者のアドレス、および送信する数量のXNUMXつのパラメーターを取ります。 それに応じて、コントラクトは次のXNUMXつのステップを実行します。
- トランザクションが送信者によって署名されたことを確認します。
- 送金者に十分な資金があることを確認してください。
- 送信者の行から要求された数量を差し引きます。
- その数量を受信者の行に追加します。
最初のXNUMXつのステップのいずれかのチェックが失敗した場合、契約は打ち切られ、支払いは行われません。
したがって、入出力モデルと契約メッセージモデルの両方が、トランザクションルールを定義して共有データベースを安全に保つための効果的な方法です。 実際、理論的なレベルでは、これらの各モデルを使用して他のモデルをシミュレートできます。 ただし、実際には、最も適切なモデルは、構築されるアプリケーションによって異なります。 各トランザクションが影響する情報の数は少ないですか、それとも多いですか？ トランザクションの独立性を保証できる必要がありますか？ 各データには明確な所有者がいますか、それとも共有すべきグローバルな状態がありますか？
これらのXNUMXつのモデル間の選択に回答がどのように影響するかを調査することは、ここでは私たちの範囲を超えています。 ただし、一般的なガイドラインとして、新しいブロックチェーンアプリケーションを開発するときは、トランザクションルールを両方の形式で表現して、どちらがより自然に適合するかを確認することをお勧めします。 この違いは、（a）プログラミングの容易さ、（b）ストレージ要件とスループット、および（c）競合検出の速度の観点から表されます。 この最後の問題については後で詳しく説明します。
組み込みルール
トランザクションルールに関しては、マルチチェーンがファブリック、イーサリアム、およびコーダと明確に異なるXNUMXつの方法があります。 これらの他のプラットフォームとは異なり、MultiChainには、ブロックチェーン駆動のアプリケーションにいくつかの基本的なビルディングブロックを提供する組み込みの抽象化がいくつかあります。 必要 開発者が独自のコードを記述します。 これらの抽象化は、一般的に必要とされるXNUMXつの領域をカバーします：（a）動的アクセス許可、（b）譲渡可能な資産、および（c）データストレージ。
たとえば、MultiChainは、ネットワークへの接続、トランザクションの送受信、アセットまたはストリームの作成、または他のユーザーの権限の制御のための権限を管理します。 複数の交換可能な資産を安全かつアトミックに発行、転送、廃棄、または交換できます。 チェーン上に任意の数の「ストリーム」を作成して、JSON、テキスト、またはバイナリ形式のチェーン上またはチェーン外のデータをパブリッシュ、インデックス作成、および取得できます。 これらの抽象化のトランザクションルールはすべて、すぐに使用できます。
マルチチェーンでアプリケーションを開発する場合、この組み込み機能を無視して、スマートフィルターのみを使用してトランザクションルールを表現することができます。 ただし、スマートフィルターは、組み込みの抽象化と一緒に動作するように設計されており、デフォルトの動作を有効にすることで、 制限されました カスタマイズされた方法で。 たとえば、特定のアクティビティの権限は、管理者が行うデフォルトの動作ではなく、特定の管理者によって制御される場合があります。 特定の資産の譲渡は、時間によって制限されたり、特定の金額を超える追加の承認が必要になる場合があります。 特定のストリームのデータを検証して、必要なフィールドと値を持つJSON構造のみで構成されていることを確認できます。
これらすべてのケースで、スマートフィルターはトランザクションを検証するための追加の要件を作成しますが、 削除します これは、組み込みのシンプルなルールです。これは、ブロックチェーンアプリケーションの重要な課題のXNUMXつに対処するのに役立ちます。あるチェーンコードのバグが悲惨な結果につながる可能性があるという事実。 私たちはこの問題の無限の例を公開イーサリアムブロックチェーンで見ました、最も有名なのは DAOの終焉 と パリティ多重署名のバグ. より広範な調査 攻撃者が他の人々の資金を盗んだり凍結したりできるようにするイーサリアムのスマートコントラクトに多数の一般的な脆弱性を発見しました。
もちろん、マルチチェーンスマートフィルターにもバグが含まれている可能性がありますが、その影響の範囲はより限定されています。 たとえば、組み込みのアセットルールは、スマートフィルターに含まれている他のロジックに関係なく、あるユーザーが別のユーザーのお金を費やしたり、自分のお金を誤って消したりするのを防ぎます。 スマートフィルターにバグが見つかった場合は、元帳の基本的な整合性が保護されている間、バグを非アクティブ化して修正バージョンに置き換えることができます。 哲学的には、MultiChainは、データベースプラットフォームが列、テーブル、インデックス、制約などの多くの組み込みの抽象化を提供する従来のデータベースアーキテクチャにより近いものです。 トリガーやストアドプロシージャなどのより強力な機能は、実際に必要な場合に、オプションでアプリケーション開発者がコーディングできます。
| 取引ルール | ファブリック | マルチチェーン | Ethereum | ロープ |
|---|---|---|---|---|
| モデル | 契約メッセージ | 入出力 | 契約メッセージ | 入出力 |
| ビルトイン | なし | 権限+ アセット+ストリーム |
なし | なし |
決定論
対決の次の部分に移りましょう。 どのアプローチを選択しても、ブロックチェーンアプリケーションのカスタムトランザクションルールは、アプリケーション開発者が作成したコンピューターコードとして表現されます。 また、集中型アプリケーションとは異なり、このコードはトランザクションごとに複数回、複数の場所で実行されます。 これは、さまざまな参加者に属する複数のブロックチェーンノードが、それぞれトランザクションを確認または実行する必要があるためです。
この繰り返しの冗長なコード実行により、集中型アプリケーションではめったに見られない新しい要件、決定性が導入されます。 計算のコンテキストでは、確定性とは、コードが実行される場所とタイミングに関係なく、コードの一部が常に同じパラメーターに対して同じ答えを返すことを意味します。 これは、ブロックチェーンと相互作用するコードにとって絶対的に重要です。決定論がなければ、そのチェーン上のノード間のコンセンサスは壊滅的に破壊される可能性があるためです。
最初に入出力モデルで、これが実際にどのように見えるかを見てみましょう。 XNUMXつのノードがトランザクションが有効であるかどうかについて異なる見解を持っている場合、一方はそのトランザクションを含むブロックを受け入れ、もう一方は受け入れません。 すべてのブロックは明示的に前のブロックにリンクして戻るため、これによりネットワークに永続的な「分岐」が作成され、XNUMXつ以上のノードがその時点以降のブロックチェーン全体のコンテンツに関する多数意見を受け入れなくなります。 少数派のノードはデータベースの進化状態から切り離され、アプリケーションを効果的に使用できなくなります。
次に、契約メッセージモデルで合意が崩れた場合にどうなるかを見てみましょう。 契約が特定のメッセージにどのように応答するかについてXNUMXつのノードが異なる意見を持っている場合、これにより、データベースの内容に違いが生じる可能性があります。 これは、他のコントラクトに送信するメッセージを含む、将来のメッセージに対するコントラクトの応答に影響を与える可能性があります。 最終結果として、データベースの状態に対する異なるノードのビュー間の相違が大きくなります。 （Ethereumブロックの「状態ルート」フィールドは、契約の応答におけるあらゆる差異が、一定期間非表示にとどまるリスクを負うのではなく、完全に壊滅的なブロックチェーンフォークに直ちにつながることを保証します。）
非決定論の原因
したがって、ブロックチェーンコードの非決定性は明らかに問題です。 しかし、算術などの計算の基本的なビルディングブロックが確定的である場合、何を心配する必要がありますか？ ええと、結局のところ、かなりの数のことがわかります。
- 明らかに、乱数ジェネレーターは、定義により毎回異なる結果を生成するように設計されているためです。
- 現在の時刻をチェックします。ノードがまったく同時にトランザクションを処理することはなく、いずれにしても、それらのクロックは同期していない可能性があります。 （ブロックチェーン自体の中でタイムスタンプを参照することにより、時間依存のルールを実装することはまだ可能です。）
- インターネット、ディスクファイル、またはコンピューターで実行されている他のプログラムなどの外部リソースのクエリ。 これらのリソースは常に同じ応答をすることを保証できず、使用できなくなる可能性があります。
- 複数のコードを並行して「スレッド」で実行すると、これらのプロセスの終了順序を予測できない「競合状態」が発生します。
- さまざまなコンピュータープロセッサアーキテクチャで微妙に異なる答えを与える可能性のある浮動小数点計算を実行します。
私たちのXNUMXつのブロックチェーンプラットフォームは、これらの落とし穴を回避するためにいくつかの異なるアプローチを採用しています。
確定的実行
そのアプローチが最も「純粋」であるため、イーサリアムから始めましょう。 イーサリアム契約は、「イーサリアムバイトコード」と呼ばれる特別な目的の形式で表現され、イーサリアム仮想マシン（「EVM」）によって実行されます。 プログラマーはバイトコードを直接書き込むのではなく、Solidityと呼ばれるJavaScriptのようなプログラミング言語からバイトコードを生成または「コンパイル」します。 （他の言語は以前は利用可能でしたが、廃止されました。）確定性は、SolidityとEthereumバイトコードが非確定的操作をエンコードできないという事実によって保証されています。これはとても簡単です。
マルチチェーンフィルターとCordaコントラクトは、既存のプログラミング言語とランタイム環境を適応させることにより、異なるアプローチを選択します。 マルチチェーンは、Googleで実行されているJavaScriptを使用します V8 エンジン。これもChromeブラウザーとNode.jsプラットフォームの中核を形成しますが、非決定論のソースは無効になっています。 同様に、CordaはJavaまたは コトリン、どちらもJava仮想マシン（「JVM」）内で実行される「Javaバイトコード」にコンパイルされます。 現時点では、CordaはOracleの標準的な非決定論的JVMを使用していますが、 確定的バージョン。 一方、Corda契約の開発者は、コードに非決定性を許可しないように注意する必要があります。
イーサリアムの純粋主義は、マルチチェーンとコルダが採用した進化的アプローチとどのように比較されますか？ イーサリアムの主な利点は、リスクの最小化です。組み込みの目的の仮想マシンには、非決定性の不注意なソースが含まれている可能性が低くなります。 そのような見落としはソフトウェアの更新によって修正できますが、遭遇するほど運が悪かったチェーンを破壊することになります。 ただし、Ethereumの問題は、SolidityとEVMが、プログラミング言語とランタイム環境の幅広いコンテキストで小さな初期のエコシステムを構成していることです。 比較すると、JavaScriptとJavaは Githubの上位XNUMX言語、何十億ものデジタルデバイスで実行され、数十年にわたって最適化されたランタイムを備えています。 おそらくこれが、パブリックイーサリアムブロックチェーンがへの移行を検討している理由です eWASM、新しいWebAssembly標準の確定的な分岐。
推奨による決定論
決定論に関しては、Hyperledger Fabricはまったく異なるアプローチを採用しています。 ファブリックでは、「クライアント」ノードがいくつかのチェーンコードにメッセージを送信する場合、最初にそのメッセージをいくつかの「エンドーサー」ノードに送信します。 これらの各ノードはチェーンコードを個別に実行し、メッセージの意見を形成します 効果 そのチェーンコードのデータベースで。 これらの意見は、正式な「承認」を構成するデジタル署名とともにクライアントに送り返されます。 クライアントが意図した結果の十分な承認を受け取った場合、クライアントはそれらの承認を含むトランザクションを作成し、チェーンに含めるためにブロードキャストします。
確定性を保証するために、チェーンコードの各部分には、トランザクションを有効にするために必要な承認のレベルを正確に定義する「保証ポリシー」があります。 たとえば、あるチェーンコードのポリシーには、ブロックチェーンのノードの少なくとも半分からの承認が必要であると記載されている場合があります。 もうXNUMXつは、XNUMXつの信頼できる当事者のいずれかからの承認を必要とする場合があります。 どちらの方法でも、必要な推奨が受け取られたかどうか、すべてのノードが個別にチェックできます。
違いを明確にするために、ほとんどのブロックチェーンプラットフォームの決定論は、「このデータに対してこのコードを実行した結果はどうなりますか？」という質問に基づいています。 –そして、すべてのノードがこの質問に同じように答えることを完全に確認する必要があります。 対照的に、Fabricの決定論は別の質問に基づいています。「このデータに対してこのコードを実行した結果について、十分な支持者が同意しているか？」 これに答えることは数えるというかなり単純な問題であり、非決定論が入り込む余地はありません。
ファブリックの承認による決定論には、興味深い結果が数多くあります。 まず、チェーンコードは多くの異なるプログラミング言語で記述できます。なぜなら、これらは決定論に適合させる必要がないためです（現在、Go、Java、JavaScriptがサポートされています）。 第XNUMXに、クライアントとエンドーサーのみが実行する必要があるため、ブロックコードの一部の参加者からチェーンコードを隠すことができます（データベース自体はグローバルに表示されます）。 最後に、最も注目すべき点として、Fabricチェーンコードは、オンラインWeb APIを使用して天気をチェックするなど、他のブロックチェーン環境で禁止されていることを実行できます。 すべての承認者がこのAPIから異なる回答を取得する最悪の場合、クライアントは特定の結果に十分な承認を取得できず、トランザクションは実行されません。 （Fabricチームのメンバーはまだ 推奨する サプライズを回避するために、チェーンコード内で決定論的ロジックを使用します。）
ファブリックはこの柔軟性に対してどのような代価を払っていますか？ ブロックチェーンの目的が共有のデータベース駆動型アプリケーションから仲介者を削除することである場合、Fabricのエンドーサーへの依存は、その目標から大きな一歩を踏み出します。 チェーンの参加者にとって、チェーンコードのルールに従うだけではもはや十分ではありません–彼らはまた、そうしたことに同意するために特定の他のノードを必要とします。 さらに悪いことに、承認者の悪意のあるサブセットは、チェーンコードにまったく従わないデータベースの変更を承認する可能性があります。 これにより、承認者は通常のブロックチェーンのバリデーターよりもはるかに強力になります。 ブロックチェーンアプリケーション開発者は、特定のケースでこのトレードオフが理にかなっているかどうかを判断する必要があります。
| 決定論 | ファブリック | マルチチェーン | Ethereum | ロープ |
|---|---|---|---|---|
| モデル | 推薦 | 適応ランタイム | 専用のVM | 適応ランタイム |
| ESL, ビジネスESL <br> 中国語/フランス語、その他 | Go + Java + JavaScript | JavaScriptを | 固まり | Java + コトリン |
| コードの可視性 | 取引先+ 支持者 |
ブロックチェーン | ブロックチェーン | 取引先+ 扶養家族 |
| 実施済み | いいえ | 有り | 有り | いいえ（現時点では） |
紛争予防
これまで、さまざまなブロックチェーンプラットフォームがトランザクションルールをコードでどのように表現するか、そしてすべてのノードがそれらのルールを同じように適用することを確定的に保証する方法について説明しました。 次に、対決の10つ目の側面について説明します。各プラットフォームは、それ自体で有効な8つのトランザクションが互いに競合する可能性にどのように対処しますか？ 最も単純な例では、アリスが財務台帳に$ 7を持ち、ボブに$ XNUMXを送るトランザクションとチャーリーに$ XNUMXを送るトランザクションのXNUMXつをブロードキャストするとします。 明らかに、これらのトランザクションのXNUMXつだけが成功することができます。
XNUMXつのモデル
まず、この問題に対するMultiChainとCordaのアプローチをグループ化することから始めます。 前に説明したように、これらは両方とも、トランザクションとそのルールを表すために入出力モデルを使用しており、各トランザクション入力は前のトランザクション出力を使用します。 これは、競合を防止するための単純な原則につながります。すべての出力は10回しか使用できません。 マルチチェーンフィルターとCordaコントラクトは、それぞれのプラットフォームに依存して、この制限を完全に実施できます。 Aliceの$ XNUMXは前のトランザクション出力によって表されるため、この単一支出ルールは、AliceがBobとCharlieの両方に送信することを自動的に停止します。
この類似性にもかかわらず、MultiChainとCordaが競合をどのように防止するかについての重要な違いを指摘することが重要です。 マルチチェーンでは、すべてのノードがすべてのトランザクションを参照するため、各出力がXNUMX回だけ使用されることを個別に確認できます。 以前に確認されたトランザクションに対してXNUMX倍の支出を行うトランザクションは、即座に自動的に拒否されます。 対照的に、Cordaにはグローバルブロックチェーンがないため、これらの二重の支出を防ぐために「公証人」が必要です。 Cordaのすべての出力状態は公証人に割り当てられます。公証人は、その出力を使用するトランザクションに署名し、以前に使用されていないことを確認する必要があります。 ブロックチェーンの参加者は公証人を信頼してこのルールを正直に守らなければなりません。悪意のある公証人は思いのままに大混乱を引き起こす可能性があります。 ファブリックの推奨と同様に、これはサービスとしての単一支出」設計には機密性の面で利点がありますが、ブロックチェーンのグレインに反して、仲介者を再導入します。 （Corda公証人はコンセンサスアルゴリズムを使用して参加者のグループによって実行できるため、元帳の整合性を個々の不正行為者から保護できることを明確にすることが重要です）。
イーサリアムに移りましょう。 思い出すために、イーサリアムは入力と出力ではなくコントラクトとメッセージを使用します。 その結果、アリスのXNUMXつの支払いなどのトランザクションの競合は、ブロックチェーンエンジンにすぐには表示されません。 代わりに、それらは 縮小することはできません。 チェーンで注文が確認された後、トランザクションを処理します。 アリスの各支払いを処理するとき、契約は彼女の残高が十分かどうかを確認します。 ボブに8ドルを支払うトランザクションが最初に来ると、通常どおりに処理され、アリスのアカウントに2ドルが残ります。 その結果、契約がチャーリーに$ 7を支払うXNUMX番目のトランザクションを処理するときに、アリスに必要な資金が不足していることがわかり、トランザクションは中止されます。
出力と契約
これまで、競合するトランザクションを防止するためのXNUMXつの異なる手法を見てきました。MultiChainとCordaでの単一支出の出力と、Ethereumでの契約ベースの検証です。 どちらが良いですか？
この質問への回答を助けるために、GavinとHelenに代わって$ 1を保持し、どちらかが独立してそのお金を使うことを許可する「2-of-100 multisignature」アカウントの例を考えてみましょう。 ギャビンは自分のアプリケーションに80ドルをドナに支払うように指示し、数秒後、ヘレンは40ドルをエドワードに送ろうとしています。 両方の支払いに十分な資金がないため、これらのトランザクションは必然的に競合します。 両方のトランザクションがブロードキャストされる場合、結果は、最初にチェーンに入れられた方によって決定されます。 アリスの例とは異なり、この競合は 誤って、誰もアプリケーションのルールを破ろうとしているわけではないので、彼らには不運なタイミングがあっただけです。
この競合が発生する可能性を考慮すると、重要な質問は次のとおりです。Gavinがトランザクションを送信してから、支払いが失敗する可能性があることをHelenのノードが認識するまでにどのくらいかかりますか？ この期間が短いほど、ヘレンがその支払いを試みなくなり、彼女と彼女のアプリケーションをその後の驚きから救う可能性が高くなります。
入出力モデルでは、XNUMXつのトランザクションが同じ以前の出力を費やすことを明示的に試みるため、トランザクション間の競合はブロックチェーンプラットフォームに直接表示されます。 MultiChainでは、これはGavinのトランザクションがHelenのノードに伝播するとすぐに、通常XNUMX秒以内に発生します。 Cordaでは、出力の公証人がヘレンのトランザクションへの署名の要求を拒否します。これは、Gavinの署名がすでに行われているため、ヘレンは支払いが失敗することを即座に認識します。 （Corda公証書自体が配布されている場合でも、彼女は返信を数秒待つ必要があるかもしれません。）どちらの方法でも、トランザクションがブロックチェーンで確認されて注文されるのを待つ必要はありません。
イーサリアムのモデルはどうですか？ この場合、ブロックチェーンプラットフォームが競合が発生することをすぐに知る方法はありません。 Helenのノードはネットワーク上でGavinのトランザクションを確認できますが、これがHelenのトランザクションにどのように影響するかはわかりません。これは、その観点から、これらは同じコントラクトに送信されるXNUMXつのメッセージにすぎないためです。 おそらくXNUMX秒後、競合するトランザクションの最終的な順序がブロックチェーンで確認されると、ヘレンのノードは期待される結果ではなく実際のトランザクションを再計算し、アプリケーションはそれに応じて表示を更新します。 その間、GavinとHelenはどちらも暗闇の中に残されます。
ただし、このことから、入出力モデルが常に最適に機能すると結論付けるべきではありません。 GavinとHelenの両方が、元の残高である$ 40から、より少ない$ 100の支払いをまったく同時にリクエストするというシナリオ例のバリエーションを考えてみます。 入出力モデルでは、これらのトランザクションは両方ともその$ 100を含む同じデータベース行を費やしており、XNUMXつの支払いのみが成功するため、競合します。 しかし、イーサリアムでは、アカウントに両方の十分な資金が含まれているため、最終的な注文に関係なく、両方のトランザクションが正常に処理されます。 この場合、イーサリアムはギャビンとヘレンの意図をより忠実に満たします。
読み書きセット
最後に、推奨ベースのアプローチがこれらXNUMXつの手法のハイブリッドであるファブリックについて話しましょう。 前に説明したように、ファブリックの「クライアント」ノードが契約にメッセージを送信する場合、まず、承認ノードにメッセージを実行するよう依頼します。 承認ノードは、Ethereumと同様の方法（ローカルデータベースに対してコントラクトを実行する）でこれを行いますが、このプロセスはすぐに適用されるのではなく監視されます。 各承認者は、読み書きされる行のセットを記録し、その時点での行の正確なバージョンも記録します。 バージョン管理された行のこの「読み書きセット」は、裏書きで明示的に参照され、クライアントがブロードキャストするトランザクションに含まれます。
ファブリックトランザクション間の競合は、チェーン内で注文が確定すると解決されます。 すべてのノードが各トランザクションを個別に処理し、推奨ポリシーをチェックして、指定されたデータベースの変更を適用します。 ただし、トランザクションが前のトランザクションによってすでに変更されているデータベース行バージョンを読み書きする場合、その10番目のトランザクションは無視されます。 ボブとチャーリーへのアリスの競合する支払いに戻るために、これらのトランザクションは両方とも、アリスが開始したXNUMXドルを含む同じ行バージョンを読み取り、変更します。 したがって、XNUMX番目のトランザクションは安全かつ自動的に中止されます。
競合解決へのファブリックのアプローチは問題なく機能しますが、パフォーマンスと柔軟性の点で、前の40つのモデルの最悪のものを組み合わせています。 裏書によりトランザクションが特定の読み書きセットに変換されるため、GavinとHelenの同時であるが互換性のある$ XNUMXの支払いは、Ethereumが回避する競合につながります。 ただし、承認者はブロックチェーンによって確認されたデータベースの最新バージョンに対して契約を実行し、未確認のトランザクションを無視するため、Fabricは入出力モデルの速度の利点を獲得しません。 したがって、Gavinの数秒後、ブロックチェーンでGavinが確認される前にHelenが支払いを開始すると、Fabricは純粋な入出力モデルが回避する競合するトランザクションを作成します。
| 紛争予防 | ファブリック | マルチチェーン | Ethereum | ロープ |
|---|---|---|---|---|
| モデル | 読み書きセット | 単一の支出 | 契約チェック | 単一の支出 |
| Verification | 独立した | 独立した | 独立した | 信頼できる公証人 |
| 速度 | 〜10s（確認） | 〜1s（伝播） | 〜10s（確認） | 0〜5s（公証） |
複雑な選択
この部分では、Corda、Ethereum、Fabric、MultiChainが「スマートコントラクト」、またはブロックチェーンに埋め込まれたアプリケーションコードの主要な課題に対処するさまざまな方法の多くをレビューしました。 また、プラットフォームごとにXNUMXつの主要な質問に対する答えが異なります。トランザクションルールはどのように表されますか？ コードはどのように確定的に実行されますか？ そして、どのようにして対立を防ぐのでしょうか？
では、スマートコントラクトの対決の勝者は誰ですか？ 簡単な答えがないことは今では明らかです。 各プラットフォームは、柔軟性、シンプルさ、パフォーマンス、中傷、安全性、機密性の間の複雑なマルチウェイトレードオフを表しています。 したがって、特定のアプリケーション用のプラットフォームの選択は、そのアプリケーションの信頼モデル、それに含まれるトランザクションの種類、および競合の可能性の高いパターンを詳細に理解することから始める必要があります。 これらの質問への答えがわかる前に特定のスマートコントラクトソリューションを推進している人を見つけた場合は、「よりスマートな」アプローチを採用するように丁寧にしかし断固として主張することをお勧めします。
コメントを投稿してください LinkedInの上に.
