スマートコントラクトに関する3つの最も一般的な誤解

人気のブロックチェーン プラットフォームの開発者として、Ethereum のようなスマート コントラクトがマルチチェーン ルートを採用するかどうかを尋ねられることがあります。私はいつもこう答えます。「いいえ、少なくとも今のところは。」

しかし、誇大宣伝に満ちたブロックチェーンの世界でスマート コントラクトが大流行しているのなら、なぜそれ以前に流行していなかったのでしょうか?問題は、ビットコイン ブロックチェーンの 3 つの最も強力な使用例 (出所、企業間の記録保持、軽量な資金調達) が理解されている一方で、イーサリアムのスマート コントラクトに相当するものがまだ見つかっていないことです。

だからといって、スマート コントラクトを活用したい人にとってアイデアが不足していないというわけではありません。それどころか、これらのアイデアの多くは実現不可能なものなのです。ご存知のとおり、賢い人たちは「スマート コントラクト」という言葉を聞くと、想像力を膨らませがちです。彼らは、自動化されたインテリジェントなソフトウェアが世界に統合され、そのデータを活用して楽しみに参加することを想像しています。

残念ながら、スマート コントラクトの現実はこれよりもはるかに平凡です。

スマート コントラクトは、実際にはブロックチェーンに保存され、ブロックチェーン トランザクションによってトリガーされるコードです。

ブロックチェーンデータベース内のデータを読み書きします。これはスマートコントラクトです。本物。スマート コントラクトは、ブロックチェーン上で実行され、ブロックチェーンの状態モデルと対話する、派手な名前の付いたコードです。コードとは何ですか?コードは Pascal、Python、または PHP になります。それは Java であり、Fortran であり、C++ です。データベースについて言えば、それは拡張 SQL で記述されたストアド プロシージャです。これらの言語はすべて基本的に同等であり、同じ種類の問題を解決します。もちろん、どの言語にも長所と短所があります。C で Web サイトを構築したり、Ruby で HD ビデオを圧縮したりするなんて、狂気の沙汰です。しかし、少なくとも原則的には、望むなら可能です。利便性とパフォーマンスの面で大きな代償を払うことになります。

スマート コントラクトの問題は、期待が誇張されているというだけではありません。こうした期待のせいで、多くの人が実現不可能なアイデアに時間とお金を浪費してしまうのです。大企業には、上級管理職が新しいテクノロジーに出会い、その利点と限界を真に理解するまでの長い道のりを乗り越えるリソースが必要であるように思われます。おそらく私たち自身の経験がこの時間を短縮するのに役立つでしょう。

過去 9 か月間、私たちは数多くのスマート コントラクトの使用事例を提案してきましたが、何度も、自分たちでは絶対にできない対応策を見つけました。最終的に、スマート コントラクトに関する最も一般的な誤解を 3 つ特定しました。技術が成熟しておらず、ツールがまだ利用できないため、これらのアイデアには何の問題もありません。むしろ、単一のデータベース内でコードを分散的に実行するという基本的な性質を誤解しています。

外部サービスへのお問い合わせ

通常、スマート コントラクトに提案される最初のユース ケースは、何らかの外部イベントに応じて動作を変更するものです。たとえば、特定の月の降雨量に基づいて保険金が支払われる農業保険などです。想定されるプロセスは、スマートコントラクトがスケジュールされた時間まで待機し、外部サービスから天気予報を取得し、受信したデータに基づいて適切なアクションを実行するという、おおよそ次のようになります。

すべては単純に聞こえるが、同時に不可能なことでもある。なぜ？ブロックチェーンはコンセンサスベースのシステムであるため、トランザクションの処理後にすべてのノードが同じ状態に達した場合にのみ機能します。これらすべては、ブロックチェーンが完全に決定論的であり、矛盾が生じる可能性がない場合にのみ存在できます。 2 つの正直なノードがチェーンの状態について意見が一致しなくなった瞬間、システム全体が無価値になります。

ここで、スマート コントラクトはチェーン上の各ノードによって独立して実行されることを思い出してください。したがって、スマート コントラクトが外部ソースから何らかの情報を取得する場合、その情報は繰り返し取得され、各ノードによって個別に実行されます。ただし、情報のソースはブロックチェーンの外部にあるため、すべてのノードが同じ回答を受け取るという保証はありません。情報ソースは、異なるノード間の要求に対する応答時間を変更したり、一時的に利用できなくなったりする可能性があります。いずれにせよ、コンセンサスが崩れると、ブロックチェーン システム全体が麻痺してしまいます。

それで、解決策はあるのでしょうか?実は、とても簡単です。スマート コントラクトを介して外部データの取得を開始する代わりに、1 つ以上の信頼できる当事者 (「データベース」) による取得の作成によって、データがトランザクション チェーンに埋め込まれます。各ノードにはデータの同一のコピーが存在するため、スマート コンピューティング コントラクトで安全に使用できます。言い換えれば、スマートコントラクトでデータを引き出すよりも、データベースでブロックチェーンにデータをプッシュする方がはるかに優れています。

スマート コントラクトが外部イベントのトリガーを伴う場合にも同様の問題が発生します。たとえば、スマート コントラクトが銀行 API を呼び出して送金を完了するというアイデアは、多くの人に好まれています。各ノードがチェーン内のコードを個別に実行する場合、このプログラム インターフェイスを呼び出す責任は誰にあるのでしょうか?答えが特定のノードである場合、その特定のノードに障害が発生するとどうなるでしょうか?まだ冷静でいられますか？答えがすべてのノードである場合、このインターフェースを持つすべてのノードのパスワードを信頼できますか?この API を本当に何百回も呼び出す必要があるのでしょうか?さらに悪いことに、スマート コントラクトが API 呼び出しが成功したかどうかを知る必要がある場合、外部データに依存するという問題に戻ってしまいます。

いつものように、簡単な解決策があります。スマート コントラクトが外部 API を呼び出す代わりに、信頼できるサーバーを使用してブロックチェーンの状態を監視し、それに応じて特定の操作を実行します。たとえば、銀行はブロックチェーンを積極的に監視し、資金移動を実行し、取引をチェーン上に反映することができます。チェーンは完全に受動的な役割を果たすため、ブロックチェーンのコンセンサスにリスクをもたらすことはありません。

これら 2 つのソリューションを見ると、いくつかのことがわかります。まず、ブロックチェーンと外部世界とのやり取りを処理するために、信頼できるエンティティが必要です。これは技術的には可能ですが、分散型システムの目標に反します。第二に、これらのソリューションでデータベースの読み取りと書き込みに使用されるメカニズムは、わかりやすい例です。外部情報のデータベースを提供し、この情報をチェーンに書き込むだけです。これはブロックチェーンの状態を反映しており、現実世界で必要なのはチェーンからデータを読み取ることだけです。言い換えれば、ブロックチェーンと外部世界との間のやり取りは、通常のデータベース操作に限定されます。これについては後ほど詳しく説明します。

オンチェーン決済の実施

私たちがよく耳にするもう一つの提案は、スマート コントラクトを使用してクーポンの支払いを自動化する、いわゆる「スマート ボンド」です。アイデアは、適切なタイミングでスマート コントラクトの支払いコードを自動的にトリガーし、手動プロセスを回避しながら、発行者がデフォルトできないようにすることです。

もちろん、これが機能するためには、返済に使用される資金がブロックチェーン内で循環される必要があります。そうしないと、スマートコントラクトは支払いを保証できません。ここで、ブロックチェーンはデータベースであり、この場合は発行された債券と現金の一部を含む財務台帳であることを思い出してください。したがって、クーポン支払いについて話すとき、実際には合意された時間に自動的に実行されるデータベース操作について話していることになります。

このような自動化は技術的には実現可能だが、常に財政的な困難に悩まされてきた。債券の支払いに使用される資金が債券のスマート コントラクトによって制御されている場合、それらの支払いは確かに保証されます。しかし、これは債券発行者が資金を他の目的に使用できないことも意味します。これらの資金がスマート コントラクトの管理下にない場合、支払いが確実に行われることを保証する方法はありません。

言い換えれば、スマート債券は、無意味な発行者か無意味な投資家のどちらかです。考えてみれば、これはまったく明白な結果です。投資家の観点から見ると、債券の最大のポイントは魅力的な収益率ですが、一定のデフォルトリスクのコストが伴います。発行者にとって、債券の目的は生産資金を調達することですが、新しい工場の建設など、一部の活動にはリスクが伴います。したがって、債券発行者が投資家への返済を保証しながら資金を調達する方法はありません。これは驚くべきことではありません。リスクとリターンの関係はブロックチェーンが解決できる問題ではないからです。

機密データの隠蔽

以前にも書いたように、ブロックチェーンを効果的に使用する上での最大の課題は、ブロックチェーンが提供する透明性のレベルです。たとえば、10 の銀行が協力してブロックチェーンを構築し、そのうちの 2 つの銀行が双方向の取引を行った場合、その取引は他の 8 つの銀行にすぐに表示されます。この問題を緩和するさまざまな戦略がありますが、誰が何を閲覧できるかを完全に制御できる信頼できる管理者がいない限り、中央データベースのシンプルさに勝るものはありません。

スマートコントラクトがこの問題を解決できると考える人もいます。彼らは、各スマート コントラクトには独自の小型データベースが含まれており、それを完全に制御できると主張しています。データベース内のすべての読み取りおよび書き込み操作はコントラクト コードによって仲介されるため、コントラクトは他のデータを直接読み取ることはできません。 (データとコードのこの密接な結合は埋め込みと呼ばれ、一般的なオブジェクト指向プログラミング パラダイムの基礎となっています。)

では、スマート コントラクトが他のデータにアクセスできない場合、ブロックチェーンの機密性の問題は解決できるのでしょうか?スマートコントラクトで情報を隠すことについて議論するのは意味があるでしょうか?残念ながら、答えはノーです。スマート コントラクトが他のデータを読み取ることができない場合でも、データはチェーン内のすべてのノードに保存されます。ブロックチェーンの参加者ごとに、システムのメモリやディスクを完全に制御することが可能です。彼らが自分のシステムから情報を読み取りたい場合、それを止めるものは何でしょうか?

スマート コントラクトで Web データを隠すことは、HTML コードで隠すのと同じくらい安全です。もちろん、ブラウザウィンドウには表示されないため、平均的な Web ユーザーにはそのメッセージは表示されません。ただし、これに必要なのは、Web ブラウザーに「ソースの表示」機能を追加することだけです (すべての Web ブラウザーにこの機能があるため)。これにより、非表示の情報が普遍的に表示されるようになります。同様に、スマート コントラクトに隠されたデータの場合、誰かがブロックチェーン ソフトウェアを変更してコントラクトの完全な状態を表示するだけで、秘密の幻想が明らかになります。優秀なプログラマーであれば、これを実行するのに 1 時間程度しかかかりません。

スマートコントラクトとは何ですか?

スマート コントラクトではできないことがたくさんあるため、スマート コントラクトとは実際何なのかと疑問に思う人もいるかもしれません。しかし、この質問に答えるには、私たち自身のブロックチェーンの基本に戻る必要があります。要約すると、ブロックチェーンにより、中央管理を必要とせずに、相互に信頼していないエンティティ間でデータベースを直接かつ安全に共有できるようになります。ブロックチェーンはデータを分散化し、複雑さとコストを大幅に削減します。

すべてのデータベースは「トランザクション」を介して変更されます。トランザクションにはデータベースに対する一連の変更が含まれますが、成功しても失敗しても、全体として変更する必要があります。たとえば、財務台帳では、アリスがボブに支払いを行う場合、取引は次のように表されます。(a) アリスに十分な資金があるかどうかを確認する。 （b）アリスの口座から取引金額と同額を差し引くこと。 （ｃ）ボブの口座に同額を追加する。

従来の集中型データベースでは、これらのトランザクションは単一の信頼できる機関によって作成されます。対照的に、ブロックチェーンを利用した共有データベースでは、ブロックチェーンのどのユーザーでもトランザクションを作成できます。さらに、これらのユーザーは互いに完全に信頼していないため、実行できるトランザクションを制限するルールをデータベースに含める必要があります。たとえば、ピアツーピアの財務台帳では、各トランザクションで資金の合計額を一定に保つ必要があります。そうでなければ、ユーザーは好きなだけお金を自分に与えることができます。

これらのルールを表現する方法はいろいろ考えられますが、現在主流となっているのはビットコインとイーサリアムの 2 つのモデルです。ビットコインのアプローチは、「トランザクション制約」と呼べるもので、各トランザクションを (a) トランザクションのデータベースエントリの削除、および (b) エントリの作成という観点から評価します。財務元帳では、このルールは、削除されたエントリの合計資金額が作成された合計金額と一致しなければならないことを規定しています。 (既存のエントリを変更することは、そのエントリを削除し、その代わりに新しいエントリを作成することと同等であるとみなします。)

2 番目のモデルは Ethereum から派生したもので、スマート コントラクトです。つまり、コードを実行する前に、コントラクト内のすべてのデータを変更する必要があります。 (従来のデータベースのコンテキストでは、これは必須のストアド プロシージャと考えることができます。) 契約データを変更するには、ブロックチェーン ユーザーはコードにリクエストを送信し、コードがそれらのリクエストを満たすかどうか、またどのように満たすかを決定します。この例では、財務台帳のスマート コントラクト中央データベースの管理者として、十分な資金があるかどうかの確認、1 つのアカウントからの資金の減額、別のアカウントへの資金の追加という同じ 3 つの手順を実行する必要があります。

どちらのモデルも有効であり、上で詳しく説明したように、それぞれに長所と短所があります。要約すると、ビットコイン形式のトランザクション制限は優れたパフォーマンスと同時実行性を提供し、イーサリアム形式のスマート コントラクトはより高い柔軟性を提供します。それで、スマート コントラクトとは何かという質問に戻りますが、ブロックチェーンのスマート コントラクトの使用例は、トランザクション制限では実現できません。

スマート コントラクトの標準を考えると、ブロックチェーン上での許可を正当化する強力なユースケースになるとは、まだ思えません。私が知っている魅力的なブロックチェーン アプリケーションはすべて、管理権限と一般的なデータ ストレージ、および資産の作成、転送、保管、取引、および削除を処理する同じ Bitcoin トランザクションを使用しています。それでも、新たなユースケースが登場しています。誰かがスマートコントラクトの力を必要とし始めても、私は驚かないでしょう。あるいは、少なくとも、ビットコイン モデルの拡張です。

答えが何であれ、覚えておくべき重要なことは、スマート コントラクトは単にデータベース内で実行できるトランザクションを制限する方法であるということです。これは間違いなく便利なものであり、このデータベースを安全に共有するための鍵となります。しかし、スマート コントラクトではすべてを実行できるわけではなく、スマート コントラクトが存在するデータベースの境界から逃れることももちろんできません。

原文: http://www.multichain.com/blog/2016/04/beware-impossible-smart-contract/#userconsent#
ギデオン・グリーンスパン著
翻訳者: nous
報酬アドレス: 14Gdmj8FuC4RsuuKiEgjNirLXQXbp35SgH
編集者: カイル
出典（翻訳）：バビット情報（http://www.8btc.com/beware-the-impossible-smart-contract）