XNUMXつの最も一般的なスマートコントラクトの誤解

人気のブロックチェーンプラットフォームの開発者として、Ethereumのようなスマートコントラクトが マルチチェーン ロードマップ。 私のいつもの答えは： いいえ、または少なくともまだ.

しかし、ブロックチェーンの誇大宣伝の世界では、スマートコントラクトが大流行しています。 さて、問題は、許可されたビットコインスタイルのブロックチェーンのXNUMXつの強力なユースケース（出所、会社間レコード、軽量ファイナンス）を知っている一方で、イーサリアムスタイルのスマートコントラクトに相当するものはまだ見つかっていないことです。

スマートコントラクトで何をしたいかというアイデアが人々に不足しているわけではありません。 むしろ、これらのアイデアの多くは 単に不可能です。 賢い人々が「スマートコントラクト」という言葉を聞くと、彼らの想像力は乱暴になる傾向があります。 彼らは、自律型インテリジェントソフトウェアの夢を思い起こさせ、世界に飛び出し、そのデータを乗ってもらいます。

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

スマートコントラクトは、ブロックチェーンに格納され、ブロックチェーントランザクションによってトリガーされ、そのブロックチェーンのデータベースでデータの読み取りと書き込みを行うコードです。

それでおしまい。 本当に。 スマートコントラクトは、ブロックチェーン上で実行され、そのブロックチェーンの状態と相互作用するコードの単なる仮名です。 そして何 is コード？ それはPascal、Python、PHPです。 それはJavaであり、Fortranであり、C ++です。 データベースといえば、それは ストアドプロシージャ SQLの拡張で書かれています。 これらの言語はすべて基本的に同等であり、同じ種類の問題を同じ種類の方法で解決します。 もちろん、それぞれに長所と短所があります。CでWebサイトを構築したり、RubyでHDビデオを圧縮したりするのはおかしいでしょう。 しかし、原則として、少なくとも、。 あなたは、利便性、パフォーマンス、そしておそらくあなたの髪の毛の点で重い金額を払うでしょう。

スマートコントラクトの問題は、人々の期待が高まっているというだけではありません。 これらの期待が多くの人に、実行できない可能性のあるアイデアに時間とお金を費やしていることです。 大企業は、上級管理職が新しいテクノロジーに出会った瞬間から、そのテクノロジーの利点と限界が真に理解されるまで、長い道のりを旅するのに十分なリソースを持っているようです。 おそらく、私たち自身の経験がこの時間を短縮するのに役立ちます。

過去XNUMXか月間、多くのスマートコントラクトユースケースが提案されてきました。 その結果、最も一般的に保持されているXNUMXつのスマートコントラクトの誤解を特定しました。 テクノロジーが未成熟であるか、ツールがまだ利用できないため、これらのアイデアは間違っていません。 むしろ、彼らは誤解している データベースに存在し、分散して実行されるコードの基本的な特性.

外部サービスへの連絡

多くの場合、最初に提案されたユースケースは、外部イベントに応じて動作を変更するスマートコントラクトです。 たとえば、特定の月の降雨量に基づいて条件付きで支払いを行う農業保険証券。 想像上のプロセスは次のようなものです。スマートコントラクトは、所定の時間まで待機し、外部サービスから天気予報を取得し、受信したデータに基づいて適切に動作します。

これはすべて単純に聞こえますが、それも不可能です。 どうして？ ブロックチェーンはコンセンサスベースのシステムであるため、すべてのトランザクションとブロックを処理した後、すべてのノードが同じ状態に達した場合にのみ機能します。 ブロックチェーンで行われるすべてのことは完全に確定的でなければならず、違いが入り込む可能性のある方法はありません。XNUMXつの正直なノードがチェーンの状態について意見が一致しない瞬間、システム全体が無価値になります。

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

それでは、回避策は何ですか？ 実際、それはかなり単純です。 外部データの取得を開始するスマートコントラクトの代わりに、XNUMXつ以上の信頼できる当事者（「オラクル」）が、そのデータをチェーンに埋め込むトランザクションを作成します。 すべてのノードにこのデータの同一のコピーがあるため、スマートコントラクトの計算で安全に使用できます。 つまり、オラクル プッシュ スマートコントラクトではなくブロックチェーンへのデータ 引き それに。

外の世界でイベントを引き起こすスマートコントラクトに関しては、同様の問題が発生します。 たとえば、送金するために銀行のAPIを呼び出すスマートコントラクトのアイデアが好きです。 しかし、すべてのノードがチェーン内のコードを個別に実行している場合、このAPIの呼び出しは誰が担当するのでしょうか。 答えがXNUMXつのノードだけの場合、その特定のノードが故意に、または意図的に故障した場合はどうなりますか？ そして答えがすべてのノードである場合、そのAPIのパスワードですべてのノードを信頼できますか？ そして、本当に何百回も呼び出されるAPIが必要なのでしょうか。 さらに悪いことに、スマートコントラクトがAPI呼び出しが成功したかどうかを知る必要がある場合、外部データに依存するという問題に戻ってきます。

前と同じように、簡単な回避策を利用できます。 スマートコントラクトが外部APIを呼び出す代わりに、ブロックチェーンの状態を監視し、それに応じて特定のアクションを実行する信頼できるサービスを使用します。 たとえば、銀行はブロックチェーンを積極的に監視し、チェーン上のトランザクションを反映した送金を実行できます。 チェーンは完全に受動的な役割を果たすため、ブロックチェーンのコンセンサスにリスクはありません。

これらのXNUMXつの回避策を見て、いくつかの観察を行うことができます。 まず、どちらもブロックチェーンと外界との相互作用を管理するために信頼できるエンティティを必要とします。 これは技術的には可能ですが、分散システムの目標を損なうことになります。 次に、これらの回避策で使用されるメカニズムは、 データベースの読み書き。 外部情報を提供するオラクルは、その情報をチェーンに書き込むだけです。 そして、現実世界でのブロックチェーンの状態を反映するサービスは、そのチェーンから読み取る以外に何もしていません。 言い換えれば、ブロックチェーンと外部の世界との間の相互作用は、通常のデータベース操作に制限されています。 この事実については後で詳しく説明します。

チェーン決済の実施

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

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

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

言い換えれば、スマートボンドは発行者にとっても、投資家にとっても無意味です。 そして、あなたがそれについて考えるならば、これは完全に明白な結果です。 投資家の視点から見ると、債券の重要なポイントは、デフォルトのリスクを犠牲にして、魅力的な収益率です。 そして、発行者にとって、債券の目的は、新しい工場の建設など、生産的ではあるが多少リスクのある活動のために資金を調達することです。 投資家が返済されることを同時に保証しながら、債券発行者が調達された資金を利用する方法はありません。 それは驚きではないはずです リスクとリターンの関係はブロックチェーンが解決できる問題ではありません.

機密データを非表示にする

私がしたように 以前に書かれた、ブロックチェーンの展開における最大の課題は、それらが提供する根本的な透明性です。 たとえば、XNUMXの銀行が一緒にブロックチェーンを設定し、XNUMXつの銀行が二国間取引を行う場合、これは他のXNUMXつの銀行にすぐに表示されます。 この問題を緩和するためのさまざまな戦略がありますが、信頼できる管理者が誰が何を参照できるかを完全に制御できる中央データベースのシンプルさと効率に勝るものはありません。

スマートコントラクトでこの問題を解決できると考える人もいます。 彼らは、各スマートコントラクトが独自のミニチュアデータベースを含み、それを完全に制御できるという事実から始まります。 このデータベースに対するすべての読み取りおよび書き込み操作は、契約のコードによって仲介されるため、ある契約が別の契約のデータを直接読み取ることは不可能です。 （データとコードの間のこの密結合はカプセル化と呼ばれ、人気のあるものの基礎です オブジェクト指向プログラミング パラダイム。）

では、あるスマートコントラクトが別のスマートコントラクトにアクセスできない場合、ブロックチェーンの機密性の問題を解決できましたか？ スマートコントラクトで情報を非表示にすることは意味がありますか？ 残念ながら、答えはノーです。 XNUMXつのスマートコントラクトが別のスマートコントラクトでデータを読み取れない場合でも、そのデータはチェーン内のすべてのノードに格納されているためです。 ブロックチェーンの参加者ごとに、それはのメモリまたはディスクにあります その参加者が完全に制御するシステム。 そして、彼らが自分のシステムから情報を読み取るのを止める理由は何もありません。

スマートコントラクトでのデータの非表示は、WebページのHTMLコードでの非表示とほぼ同じくらい安全です。 確かに、通常のWebユーザーはブラウザウィンドウに表示されないため、これは表示されません。 しかし、Webブラウザーが（ソースの表示）機能を追加するだけで（すべての機能と同じ）、隠された情報が広く表示されるようになります。 同様に、スマートコントラクトに隠されているデータの場合、ブロックチェーンソフトウェアを変更してコントラクトの完全な状態を表示するだけで、機密性のすべての類似性が失われます。 半分きちんとしたプログラマなら、XNUMX時間ほどでそれを実行できます。

スマートコントラクトの目的

スマートコントラクトでは実行できない非常に多くのことを行うため、実際に何が必要かを尋ねる人もいます。 しかし、この質問に答えるためには、ブロックチェーン自体の基本に戻る必要があります。 要約すると、ブロックチェーンを使用すると、中央管理者を必要とせずに、相互に信頼していないエンティティがデータベースを直接かつ安全に共有できます。 ブロックチェーンはデータの仲介を可能にし、これは複雑さとコストの大幅な節約につながります。

すべてのデータベースは、「トランザクション」を介して変更されます。これには、そのデータベースに対する一連の変更が含まれ、全体として成功または失敗する必要があります。 たとえば、財務元帳では、アリスからボブへの支払いは、（a）アリスに十分な資金があるかどうかを確認し、（b）アリスのアカウントから数量を差し引き、（c）ボブの口座に同じ数量を追加するトランザクションによって表されます。 。

通常の集中データベースでは、これらのトランザクションは単一の信頼できる機関によって作成されます。 対照的に、ブロックチェーン駆動の共有データベースでは、そのブロックチェーンのユーザーであれば誰でもトランザクションを作成できます。 また、これらのユーザーは相互に完全に信頼しているわけではないため、データベースには、実行されるトランザクションを制限するルールを含める必要があります。 たとえば、ピアツーピアの財務台帳では、各トランザクションで資金の合計量を維持する必要があります。そうしないと、参加者は好きなだけ自由にお金を与えることができます。

これらのルールを表現するさまざまな方法を想像できますが、現時点では、それぞれビットコインとイーサリアムに触発されたXNUMXつの主要なパラダイムがあります。 「トランザクション制約」と呼ばれる可能性があるビットコイン方式は、（a）そのトランザクションによって削除されたデータベースエントリ、および（b）作成されたエントリの観点から各トランザクションを評価します。 財務台帳では、ルールは削除されたエントリの資金の合計量が作成されたエントリの合計と一致しなければならないことを述べています。 （既存のエントリの変更は、そのエントリを削除して、代わりに新しいエントリを作成することと同じであると見なします。）

イーサリアムに由来するXNUMX番目のパラダイムは、スマートコントラクトです。 これは、契約のデータに対するすべての変更は、そのコードによって実行される必要があることを示しています。 （従来のデータベースのコンテキストでは、これは 施行された ストアドプロシージャ。）契約のデータを変更するために、ブロックチェーンユーザーは リクエスト それらの要求を満たすかどうか、またどのように満たすかを決定するコードに追加します。 のように この例、財務台帳のスマートコントラクトは、集中型データベースの管理者と同じXNUMXつのタスクを実行します。十分な資金を確認し、XNUMXつの口座から差し引いて、別の口座に追加します。

これらのパラダイムはどちらも効果的であり、それぞれに長所と短所があります。 以前に詳細に議論された。 要約すると、ビットコインスタイルのトランザクション制約は優れた同時実行性とパフォーマンスを提供し、イーサリアムスタイルのスマートコントラクトは柔軟性を提供します。 したがって、スマートコントラクトの目的についての質問に戻ります。

スマートコントラクトは、トランザクション制約を使用して実装できないブロックチェーンのユースケース用です。

スマートコントラクトを使用するためのこの基準を考えると、資格のある許可されたブロックチェーンの強力なユースケースはまだ見ていません。 私が知っているすべての説得力のあるブロックチェーンアプリケーションは、ビットコインスタイルのトランザクションで実装できます。これは、許可と一般的なデータストレージ、およびアセットの作成、転送、エスクロー、交換、破棄を処理できます。 それにもかかわらず、新しいユースケースはまだ現れており、いくつかのケースがあっても私は驚かないでしょう do スマートコントラクトの力が必要です。 または、少なくとも、ビットコインパラダイムの拡張です。

答えが何であれ、覚えておくべき重要な点は、スマートコントラクトはデータベースで実行されるトランザクションを制限するためのXNUMXつの方法にすぎないということです。 これは間違いなく便利なことであり、データベースを安全に共有できるようにするために不可欠です。 しかし、スマートコントラクトは他に何もできません。また、スマートコントラクトは、それらが存在するデータベースの境界から逃れることはできません。

コメントを投稿してください LinkedInで.

出典：https://www.multichain.com/blog/2016/04/beware-impossible-smart-contract/