多くのスマートコントラクトの使用例が単純に不可能である理由

クレイジーレビュー: ギデオン・グリーンスパン博士は、Coin Sciences の創設者兼 CEO です。彼は記事の中で、スマートコントラクトの現状、性質、分類について論じました。著者は、テクノロジーを深く分析し、それをめぐる誇大宣伝を払拭することで、多くのアプリケーションケースでスマート コントラクトが効果を発揮しないのは、人々の期待が高すぎるからではなく、その本質が単なるコードの文字列に過ぎないからだと最終的に結論付けています。システムの操作も、対応するシステム手順とルールに準拠する必要があります。

翻訳: Annie_Xu

ギデオン・グリーンスパン博士は、プライベートブロックチェーンプラットフォームMultiChainをサポートする企業であるCoin Sciencesの創設者兼CEOです。

ギデオン・グリーンスパン博士

この記事では、グリーンスパン氏がブロックチェーンのスマートコントラクトと、その技術の採用に対する高い期待が与える可能性のある悪影響について説明します。

有名なブロックチェーン プラットフォームの開発者として、MultiChain プランにも Ethereum のようなスマート コントラクトがあるかどうかよく尋ねられます。私の答えは常に「いいえ、少なくとも今のところは」でした。

しかし、スマートコントラクトが注目を集めているブロックチェーンの分野で、なぜ私はいつもノーと言うのでしょうか?問題は、許可されたビットコイン ブロックチェーンの 3 つの重要な使用例 (出所、企業記録保持、マイクロファイナンス) がわかっている一方で、イーサリアム スマート コントラクトに代わるものがまだ見つかっていないことです。

これは、人々がスマート コントラクトに何をさせたいのか分かっていないということではなく、これらのアイデアの多くは単純に実現できないということです。賢い人たちが「スマート コントラクト」という概念を聞くと、想像力が広がります。彼らは、データを持って世界中を旅することができる自律的でインテリジェントなソフトウェアを想像しています。残念ながら、スマート コントラクトの現実は非常に退屈です。

スマート コントラクトは、ブロックチェーン上のトランザクションによってアクティブ化され、データベース内のデータを読み書きするブロックチェーン上のコードです。実際のブロックチェーンとは、これだけです。

スマート コントラクトは、ブロックチェーン上で実行され、そのブロックチェーンの状態とやり取りするコードの別名です。それで、コードは何ですか? Pascal、Python、PHP、Java、Fortran、C++ が対象です。データベースが関係する場合、そのストアド プロシージャは SQL 拡張言語で記述されます。

上記のプログラミング言語はすべて基本的に同じであり、同じ問題を同じ方法で解決します。もちろん、それぞれに長所と短所があり、C で Web サイトを作成したり、Ruby で高解像度のビデオを作成したりするのは狂人だけです。しかし、原則的には、何でも好きなことができます。システムの利便性、パフォーマンス、さらには髪の毛のために支払う代償はそれだけでも高額です。

もちろん、スマート コントラクトの問題は、人々が期待しすぎるということだけではなく、こうした期待が人々を誤解させ、実現不可能なアイデアに時間とお金を浪費させてしまうことです。

大企業には長期戦を戦うためのリソースがあるようです。経営者が新しいテクノロジーに偶然出会うところから、その長所と落とし穴を認識するところまで。おそらく私たち自身の経験がこの過程を短縮するのに役立つでしょう。

過去 9 か月間で、スマート コントラクトの新しい使用例が数多く登場しました。そして、これらのアプリケーションを実装するのは不可能だということが次々と判明しています。

その結果、スマート コントラクトに関するよくある誤解を 3 つまとめることができます。もちろん、こうした誤解は、技術が未熟であったり、ツールがまだ開発されていないからというわけではありません。

むしろ、データベース内で分散的に実行されるコードの基本的な特性を誤解しているためです。

1. 外部サービスのシンジケート

スマート コントラクトの最初の使用例は通常、何らかの外部イベントに基づいて動作を変更することです。たとえば、農業保険では、特定の月の降雨量に基づいて保険契約者に一定の金額が支払われます。

想定されるプロセスは次のようになります。スマート コントラクトはスケジュールされた時間まで待機し、外部サービスから天気予報を取得し、取得したデータに基づいて適切なアクションを実行します。

簡単に聞こえるが、達成するのは不可能だ。なぜ？ブロックチェーンはコンセンサスに基づくシステムであるため、つまり、各トランザクションとブロックが処理され、すべてのノードが同じ状態に達した後にのみ、スマート コントラクトの実行が開始されます。

ブロックチェーン上で発生するすべてのことは、不一致が生じないように決定論的である必要があります。信頼できる 2 つのノードがブロックチェーンの状態について意見が一致しない場合、システム全体が完全に無価値になります。

そして、スマート コントラクトはチェーン上の各ノードによって独立して実行されるため、スマート コントラクトが外部サービスからデータを取得する場合、このデータ取得プロセスは各ノードによって独立して繰り返され、完了します。ただし、このデータはブロックチェーンの外部から取得されるため、すべてのノードが同じ回答を受け取るという保証はありません。

おそらく、これらのデータ ソースは、異なるノードからの要求を受信したときに異なる応答を返すか、一時的に使用できなくなる可能性があります。いずれにせよ、コンセンサスは崩れ、ブロックチェーン全体が崩壊します。

それで解決策は何でしょうか?実はとても簡単です。スマート コントラクトが外部データ取得指示を発行する必要はなく、必要なデータをブロックチェーンに埋め込む 1 人以上の信頼できる当事者 (予測者) によるトランザクションが必要です。すべてのノードはこのデータの同一のコピーを持っているため、スマート コントラクトの計算に使用できます。

つまり、スマート コントラクトにデータをプルさせるのではなく、予測者がデータをブロックチェーンにプッシュします。

スマート コントラクトが外部世界でイベントを引き起こす場合にも同様の問題が発生します。たとえば、銀行 API を使用して資金を送金するというアイデアは多くの人に好まれますが、各ノードがブロックチェーン コードを個別に実行する場合、この銀行 API に誰がアクセスするのでしょうか。

これを行うにはノードを選択できると言うかもしれません。しかし、意図的かどうかにかかわらず、そのノードに障害が発生した場合はどうなるでしょうか?では、API 取得を完了するためにすべてのノードを選択した場合、各ノードは信頼できるのでしょうか? API パスワードのセキュリティを確保するにはどうすればよいですか?また、API を頻繁に使用したいですか?さらに悪いことに、スマート コントラクトが API フェッチが成功したかどうかを知りたい場合、外部データに過度に依存するという厄介な状況に戻ってしまいます。

もう一度言いますが、簡単な解決策があります。スマート コントラクトは外部 API にアクセスする必要はありません。当社は信頼できるサービスを使用してブロックチェーンのステータスを監視し、それに応じたフィードバックを提供します。たとえば、銀行はブロックチェーンを積極的に監視し、オンチェーン取引に対応する資金を送金することができます。この方法では、完全に受動的であるため、ブロックチェーンのコンセンサスに脅威はありません。

これら 2 つの解決策は、次の結論にまとめることができます。

まず、ブロックチェーンと外部世界とのやり取りには信頼できるサービスが必要です。しかし、技術的には可能ではあるものの、分散型システムの目標を歪める可能性があります。

第二に、これらのソリューションで使用されるメカニズムは、データベースの読み取りと書き込みの単純でわかりやすい例です。外部情報を提供する予測者は、関連情報をブロックチェーンに書き込むだけです。ブロックチェーンの状況を現実世界に反映するサービスは、ブロックチェーンのデータを読み取るだけです。つまり、ブロックチェーンと外部世界とのやり取りは、通常のデータベース操作に限定されます。

この問題については後ほど引き続き議論する予定です。

2. オンチェーン決済を実行する

これはよく耳にする提案で、スマートコントラクトを使用して、いわゆる「スマート債券」のクーポン支払いを自動化するというものです。つまり、適切なタイミングでスマート コントラクト コードを使用して支払いを自動的に開始し、手動の手順の複雑さを回避し、発行者の実行を確実にします。

もちろん、上記の機能を実現するには、ブロックチェーン上の資金で支払いを行う必要があります。そうしないと、スマート コントラクトは支払いの完了を保証できません。

債券と現金を含む財務台帳のこのユースケースでは、ブロックチェーンは単なるデータベースであることに注意してください。したがって、クーポン支払いの場合、指定された時間内に自動的に実行されるデータベース実行について話していることになります。

自動化は技術的には可能ですが、経済的に困難です。債券のスマート コントラクトが債券の支払いに使用される資金を管理する場合、それらの支払いは保証されます。また、債券は発行者または他の誰も使用できないことを意味します。しかし、これらの資金がスマートコントラクトによって管理されていない場合、システムが支払いを行うことは保証されません。

つまり、スマートボンドは発行者にとって役に立たないか、投資家にとって効果がないかのどちらかです。考えてみれば、これは明らかな結果です。

投資家の観点から見ると、債券の最大の魅力は、一定の失敗リスクはあるものの、魅力的な収益率にあります。発行者にとって、債券の目的は、工場建設など、利益は大きいがリスクも伴う活動に資金を提供することです。発行者が資金調達を達成し、投資家が利益を得られるという保証はありません。ブロックチェーンがリスクと報酬の関係を解決できないのは当然です。

3. 機密データを隠す

以前にも書いたように、ブロックチェーンを導入する上での最大の課題は、その高い透明性です。

例えば、10 社が共同でブロックチェーンを構築し、そのうち 2 社が二国間貿易を行う場合、他の 8 社は関連情報をすぐに見ることができます。この問題を解決する方法は数多くありますが、集中型データベースのシンプルさと効率性は他に類を見ません。信頼できる管理者は情報表示チャネルを完全に制御できます。

まず第一に、各スマート コントラクトには完全に制御できる小さなデータベースが含まれているため、スマート コントラクトがこの問題を解決できると考える人もいます。このデータベースへのすべての読み取りと書き込みはコントラクト コードによって決定されるため、コントラクトが互いのデータを直接読み取ることはできません (データとコードのこの密接な接続はカプセル化と呼ばれ、一般的なオブジェクト指向プログラミング パラダイムの基礎となっています)。

では、あるスマート コントラクトが別のスマート コントラクトのデータにアクセスできない場合でも、ブロックチェーンの機密性の問題は解決されたと言えるのでしょうか?スマートコントラクトに隠された情報について議論することに意味はあるのでしょうか?残念ながら、答えはノーです。

たとえ 1 つのスマート コントラクトが別のスマート コントラクトのデータを読み取ることができなくても、関連データはブロックチェーンのすべてのノードに保存されます。各ブロックチェーン参加者は、システム ディスクまたはメモリ内のどこに情報を保存するかを完全に制御できます。彼らがそうしないことを選択しない限り、彼ら自身のシステム上のデータを読み取ることを妨げるものは何もありません。

スマート コントラクトにデータを隠すことは、Web ページの HTML コードにデータを隠すのと同じくらい安全です。もちろん、データはブラウザウィンドウに表示されないため、一般ユーザーはデータを見ることができません。必要なのは、Web ブラウザに「ソースの表示」オプションを追加することだけです (すべてのブラウザに備わっています)。そうすれば、関連情報がどこでも見えるようになります。

同様に、スマート コントラクトに隠されたデータを表示したいユーザーは、ブロックチェーン ソフトウェアを変更してコントラクトの完全な状態を表示する必要があり、すべての機密性機能が失われます。

優秀なプログラマーであれば、上記の作業を 1 時間で実行できます。

スマートコントラクトの用途

スマート コントラクトは非常に多くのことを実行できるため、その本当の目的は何なのかと疑問に思う人もいるかもしれません。この質問に答えるには、ブロックチェーン自体の基本原理に戻る必要があります。要約すると、ブロックチェーンを使用すると、相互に信頼したり中央管理者を配置したりする必要がないグループ間でデータベースを直接かつ安全に共有できます。

ブロックチェーンはデータの仲介を排除し、複雑さとコストを大幅に削減します。

トランザクションは、全体として成功または失敗する必要があるデータベースへの変更を含め、あらゆるデータベースを変更できます。たとえば、財務元帳では、A に十分な資金があるかどうかを確認するトランザクションは A から B への支払いを表し、A の口座から引き出された資金は B の口座に追加されます。

通常のデータベース内のこれらのトランザクションは、単一の信頼できる機関によって作成されます。一方、ブロックチェーンを利用した共有データベースでは、どのブロックチェーンユーザーでもトランザクションを作成できます。また、ユーザー同士が完全に信頼し合っているわけではないため、データベースにはトランザクションを制限する仕様が含まれている必要があります。

たとえば、ピアツーピアの財務台帳では、各トランザクションに十分な資金が供給されている必要があります。それ以外の場合、参加者は自由に資金を割り当てることができます。

これらのルールを表現する方法はたくさんありますが、現在は Bitcoin と Ethereum という 2 つの主要なテンプレートがあります。ビットコインのアプローチは「トランザクション制限」と呼ばれ、トランザクションによって削除されるデータベース エントリと作成されるエントリに基づいてトランザクションが評価されます。

財務元帳のルールでは、削除されたエントリの合計資金額は、作成されたエントリの資金額と等しくなければならないと規定されています (既存のエントリの変更は、エントリの削除と新しいエントリの作成に相当すると仮定します)。

2 番目の例は、Ethereum のスマート コントラクトです。これは、コントラクト データへのすべての変更をコードで実行する必要があることを規定しています (従来のデータベースの場合、これはストレージ実行プロセスと呼ぶことができます)。契約データを変更するには、ブロックチェーン ユーザーはコードにリクエストを送信する必要があります。コードでは、それらのリクエストを実行するかどうか、またどのように実行するかを決定します。

たとえば、財務台帳上のスマート コントラクトは、集中型データベースの管理者と同じ 3 つのタスクを実行します。つまり、十分な資金があるかどうかを判断し、あるアカウントから特定の金額を減算し、その金額を別のアカウントに追加します。

上記のテンプレートは両方とも有効であり、それぞれ長所と短所があります。要約すると、ビットコイン形式のトランザクション制限は優れたパフォーマンスと同時実行性を実現します。一方、Eth​​ereum スタイルのスマート コントラクトは柔軟性に優れています。

それでは、冒頭のスマート コントラクトの目的の質問に戻りましょう。スマート コントラクトは、トランザクション制限のために実行できないブロックチェーン内のアプリケーション ケースに使用されます。

スマートコントラクトアプリケーションの標準によれば、許可型ブロックチェーンには多くのアプリケーションケースがあると予測できます。

私が知る重要なブロックチェーン アプリケーションはすべて、ビットコイン スタイルのトランザクション、許可手順の実行、一般的なデータ ストレージを使用して実現できます。資産の作成、移転、保管、取引、キャンセルなども含まれます。しかし、新しいユースケースが次々と登場しており、スマート コントラクトを導入しようとするケースが出てきても不思議ではありません。あるいは、少なくともビットコイン テンプレートの拡張があるでしょう。

答えが何であれ、スマート コントラクトはデータベース内のトランザクションを制限するための手段にすぎないことを覚えておくことが重要です。

これは明らかに有用であり、安全なデータベース共有に必要です。しかし、スマート コントラクトはそれ以外のことは何もできず、それが存在するデータベースの範囲から逃れることもできません。