ついでに投下しておきます^^
翻訳元：

https://github.com/codius/codius/wiki/Smart-Oracles:-A-Simple,-Powerful-Approach-to-Smart-Contracts

ん～、理解にはもう少し時間がかかりそうです。

概要
スマート・オラクルは「スマート・コントラクト（契約）」を実施する簡単で柔軟な方法を提供し、そしてそれはビジネス論理、法律及びその他の合意された規則を暗号化します。スマート・オラクルはオラクルのアイディア、あるいは外部世界の状態に関する情報とのスマート・コントラクトを提供し、契約コードの実行と集められた情報を組み合わせる存在に基づいています。そのようなシステムでは、規則は何らかのプログラム言語で記述され、契約は暗号化された署名コマンドを受け付ける何らかのサービスと相互に作用します。これには暗号化通貨ネットワークが含まれますが、これだけに限定されません。私達はコード・サンドボックス(sandbox)にグーグル・ネイティブ・クライアント（Google’s Native Client）を利用しているコディウス（Codius）(ラテン語の「法律」を意味する“ius”に基づく)と呼ばれるスマート・オラクルの実行を紹介します。
本誌においては、私達はスマート・コントラクトの概念の幾つかの定義及び背景から始めます。そこから、私達はスマート・オラクルへの私達の提案へと移動し、技術的実行の詳細及びシステムのセキュリティ脅威モデルを説明します。最終節では、私達は幾つかの金融上及び非金融上のアプリケーション並びに全体としてスマート・コントラクトに対する本アプローチのより大きな可能性について説明します。

定義
スマート・コントラクト
コーネル大学法律情報研究所(Cornell Legal Information Institute)は契約を以下のように定義しています。:
法律により強制できる義務を作り出す合意。契約の基本的要素は相互の同意、配慮、能力及び適法性[…]。契約の違反に対する考えられる救済には、一般損害、間接損害、信用棄損及び特定履行を含む。
スマート・コントラクトはある条件と成果を暗号化したプログラムです。コードは事前に契約当事者により合意され、公平で中立なシステムにより誠実に実行されなければなりません。
スマート・コントラクトを開発し、活用する主要な三つのステップは以下の通りです。:
契約条件のコードへの翻訳。デジタル・システムは決定論的なので、契約違反に対する罰則及び(非決定論的な)仲裁人への委託を含めた契約の考えられるすべての成果は明白に指定されます。
実行される正確なコードの合意。実際には、当事者は通常彼らの契約を広く利用される構成可能な契約モジュールから作ります。一旦契約が合意された際には、同じコードが最後には実際に確実に実行されることが非常に重要です。決定論的コンパイル及び特有の秘密鍵対の節を参照。
信用できる方法でのコードの実行。コードは公平な第三者あるいは共謀の恐れが極めて少ない独立した実体のグループにより実行されなければなりません。スマート・コントラクトは実際にコードを常に実行することなく利用される場合もあります。この用途の場合における詳細情報はオフライン契約の節を参照してください。
従来の契約の代わりにスマート・コントラクトを利用する究極的な利点は、スピードと効率の増加、並びに契約が合意された通りに正確に実行される信頼の増加です。

オラクル
ビットコイン(Bitcoin)に組み込まれているものを含め、一部のスマート・コントラクト・システムは厳密に決定論的です。現実の世界と相互作用するために、これらのシステムは「オラクル(oracles)」と呼ばれる外部システムから送信される暗号化された署名に依存しています。
オラクルはその署名が実世界の状態を主張する信頼された実体です。署名の検証は決定論的に実施されるので、決定論的スマート・コントラクトは(非決定論的)外部世界に反応することが可能となります。

スマート・オラクル又は契約ホスト
スマート・オラクルは定義に続く節で説明されますが、私達は「スマート・オラクル」と「契約ホスト」という用語を互換的に使用していることに注意しなければなりません。この提案において、契約コードを実行するホストは、その他のシステムではそれらのシステムの外部で実行される契約に、外部世界の情報を提供するためにのみ構成されるかもしれない「オラクル」と同一です。

契約当事者
契約当事者は、契約を履行するためにスマート・コントラクトを利用することに同意する人々あるいは企業です。その他の関連する、あるいは性質の異なる実体は、契約オーサー(作成者)と契約オーナー(所有者)です。契約オーサーはコードを書いた人ですが、彼らは全く特定の契約に関連していない場合があります。例えば、オーサーがオープン・ソースのオークション契約を発行している開発者又は開発者達のグループである場合があります。契約オーナーはスマート・オラクルにより実行されるようにそれを構成している実体です。
契約オーナーは、契約当事者の一人あるいはそれらのいずれかの関係者であってはならないことに注意して下さい。

公開鍵／秘密鍵暗号法
公開鍵／秘密鍵暗号法はメッセージを暗号化し、あるいは表面上ランダムな一式の文字へ翻訳することを可能とします。メッセージが公開鍵により暗号化された場合、対応する秘密鍵の所有者のみがそれを復号あるいは解読することができます。
公開鍵／秘密鍵暗号法は秘密鍵の所有者がメッセージに暗号化された「署名をする」ことを可能とします。誰でもその署名がその秘密鍵の所有者によってのみ作成されることを決定的に実証することができます。
公開鍵／秘密鍵暗号法はスマート・オラクルの共通の使用事例の一部を確証しており、それゆえ非対称暗号化及び暗号化署名がどのように機能するかを基本的に理解することは有益です。背景に関する詳細情報については公開鍵暗号法、デジタル署名におけるウィキペディアの記事及びこの公開鍵暗号法の簡単な説明をお勧めします。

分散ネットワークとコンセンサス・データベース
このスマート・オラクルの提案は既存のすべての分散ネットワーク、コンセンサス・データベース及び暗号化通貨から独立していますが、ビットコイン(Bitcoin)とリップル(Ripple)を支えている概念により極めて触発されています。ビットコイン、ピアツーピア・ネットワーク及びデジタル通貨の紹介はbitcoin.orgを参照してください。リップル及びいずれかの種類の価値の転送のための分散プロトコルについての詳細情報はripple.comを参照してください。

オラクルからスマート・オラクルへ
スマート・コントラクト及びオラクルの概念はしばらく前から存在しています。幾つかの初期のデザイン(Bitcoinを含む)は、それらの実行が決定論的であるような要件に至る、コンセンサス・ネットワーク内部で契約を実行することに依存しています。本誌においては、システムを極めて一般化し単純化するスマート・オラクルによる契約の実行を示すことを私達は目指しています。
スマート・コントラクトの概念は1990年代後期に関係を法的に有効にし、それらをソフトウェア及びハードウェアに暗号化することは、ビジネス論理と機能性を単純化し安全にすると主張したニック・サボー氏(Nick Szabo)に広く帰することができます。彼は借用証書や財産権などの契約上の条項が埋め込まれたものを書きました。サボー氏はスマート・コントラクトの「初期の原型」として自動販売機の例を使用しました。なぜならそのハードウェアとソフトウェアは単純な契約上の合意を強制するからです。お金を挿入する人は誰でも、機械の所有者との間に全く明示的な契約が交わされていなくとも、見返りにスナックを受け取ることができます。ウェイ・デイ(Wei Dei)氏も1990年代後期の彼のBマネーの提案において、サボー氏の構想とあまり異ならない自力執行で暗号に基づいた契約を説明したデジタル契約について書いています。
最近、暗号化通貨への興味の出現と増加により、スマート・コントラクトへの興味の復活が刺激されています。数学に基づく通貨ネットワークは、スマート・コントラクトの重要な構成要素を提供しています。: 暗号化された署名と共に転送できる価値を持つデジタル資産。ビットコイン(Bitcoin)やリップル(Ripple)等のプロトコルにおける資産は公開鍵／秘密鍵暗号法により特定されるアカウントで所有されます。支払いは、その取引がアカウントの秘密鍵の所有者よってのみ作成される暗号化署名を伴う場合に実行されます。スマート・コントラクトはほとんど労力を要さずにそのような暗号化署名を作成し、それによりいずれの種類のデジタル資産の所有者の一部あるいはすべても指定されることができます。
あいにく暗号化通貨の開発者は、強力なスマート・コントラクトの言語と強固なコンセンサス・システム双方を含むシステムをデザインすることは多大な努力を要することに気付いています。ビットコインのスクリプトはビットコイン・ネットワーク上で暗号化され実行される単純な論理を見込んでいます。しかしながら、高等な論理の暗号化と信用されていないコードの実行は、統合がより一層複雑であることを証明しています。
コンセンサス・ネットワークはそれらの機能一式について保守的でなければなりません。ネットワーク内部の誰もが各変更に同意しなければならないので、その技術は比較的に修正やアップグレードするのが困難です。ビットコイン・ウィキ(Bitcoin wiki)では明示的にこの懸念に言及しており、「より複雑なオペレーション・コード[スクリプト・コマンド]の一部は、その実行に際してバグを含んでいるという懸念から無効にされ、そのようなオペレーション・コードを使用した取引がチェーンに含まれる場合には、いかなる修正もがそのチェーンをリスク分岐させうる」と記述しています。ブロック・チェーンあるいは分散元帳の分岐は、コンセンサスに基づくシステムにとっては非常に望ましくない結果をもたらすネットワークの複数競合状態を作り出すことを意味しています。
私達は、ビットコインやリップル等のような既存のコンセンサス・ネットワークの複雑さを増すことなく、安全で信頼できる方法で、強力なスマート・コントラクトを実行することが可能であると主張しています。
信頼されていないコードの実行は、コンセンサス・データベースや資産の所有権を追跡し転送するその他のサービスから分離されなければなりません。分離された契約システムは信頼されていないコードの実行を処理し、暗号化署名によるコンセンサス・データベースと相互作用することができます。これらの署名はコンセンサス・プロトコルに対して既にネイティブであり、それゆえに修正は何ら必要ありません。コンセンサス・ネットワークからの契約の分離は、契約が一度に複数のネットワーク並びに、事実上いかなる種類のオンライン・サービスとも相互作用することができる付加的利益をもたらします。これは単独のスマート・コントラクトはビットコイン、リップルとPaypal、Google、eBay等のウェブベースのサービスや、SSH、LDAP、SMTP及びXMPP等のその他のインターネット・プロトコルとさえも相互作用できることを示しています。
契約の実行が既存のシステムから分離される場合には、どこでコードが実行されるべきでしょうか。これがスマート・オラクルを必要とする理由です。
スマート・コントラクトへのほとんどの提案は、ビットコインのようなコンセンサス・ネットワークに対して内部的なものであっても、外部世界の状態に関する契約を通知する独立した実体に依存します。ビットコインの契約は、指定された条件が満たされる場合にのみネットワークへ入る署名を導入することにより、外部世界からの事実を証明するために「オラクル」に依存しています。スマート・オラクルはこの概念を一歩先に進めて、オラクルにより信頼されていないコードを実行しています。スマート・オラクルは外部世界に関する情報の提供と、契約当事者が合意したコードの実行双方が可能な信頼された、あるいは半ば信頼された実体です。

スマート・オラクルの実行
スマート・オラクルの実行は、多くの様々な形態を採ることができます。次の節で私達は、スマート・オラクルのすべてとは行かなくともほとんどについて本質的であると私達が見なす要素の一部を概略します。すなわち、主要な構成要素は、: 安全なコードの特定、コードのサンドボックス、オラクルAPI、契約をホスト及び課金するモデル、及び契約クライアントです。
私達は次の節でスマート・オラクルのより詳細な技術的情報へ入り込むことに注意しなければなりません。より大きな構図に関心があり、それらの詳細にあまり関心がない読者は最後の三節、オフライン契約、金融上のアプリケーションとその他及び結論を飛ばしても構いません。

安全なコードの特定
一旦契約当事者が彼らの取り決めに合意したならば、彼らはその規則をコードへ翻訳しなければなりません。当事者達が提案されたコードを検査し、彼らが拘束されることに合意したビジネス論理を示すことを保証するのは極めて重要です。スマート・オラクルにアップロードされたコードが、彼らが既に検査したものと正確に一致することを容易に実証できることも同様に重要です。これは決定論的なコードのコンパイル、ハッシュ化、及び役割を担うモジュールのコードの再利用においてです。

決定論的コンパイル
契約のすべての当事者は最終の、機械が実行可能なコードが、彼らが合意したコードを示すことを保証することに大きな利害関係を持っています。コンパイルされた言語に対しては、これはソース・コードがそれをギティアン(Gitian)等による機械言語へコンパイルするために、再制作可能なプロセスに従って共有されなければならないことを意味します。翻訳された言語に対しては、ソース・コードを共有することで十分です。いずれにしても、スマート・オラクルにより実行される最終の指示に参加者が合意することが極めて重要です。

ハッシュ化
暗号化により安全なハッシュ値は、合意された二進数あるいはソース・コード・ファイルを特定するのに便利な方法です。ハッシュ化機能は、入力として任意の量のデータを受け入れ、短い固定長のその文字列を生成します。実際的な目的に対して、この「ハッシュ値」はいかなるテキストあるいはデータをも一意的に特定するために使用することができます。
厳密には必ずしも必要ではありませんが、私達は耐衝突性能のハッシュ化機能を利用することを推奨します。これは同一の出力ハッシュ値を持つ二つの入力を探す試みは実際的ではないことを意味しています。同一のハッシュ値を持つ機能するコードを二つ作成することは、耐第二プリイメージ性能のみを持つハッシュ化機能を利用しても並外れて困難です。しかしながら、同一のハッシュ値を持つ二つの別個の契約を誰かが作り出すことができる場合、それは深刻な問題を生じます。それゆえ、私達は耐第二プリイメージ性能と耐衝突性能を持つハッシュ化機能を推奨します。

モジュール
従来の契約は多くの場合共通の「文例集」を共有しており、スマート・コントラクトも例外ではありません。いずれのスマート・オラクル・システムも何らかの形態のコードの再利用を提供する傾向があります。これは利便性並びに安全性を付加します。
多くの契約は、良く知られ、広く利用されるモジュールの上部に構築される比較的簡単で理解するのが容易な論理を持っています。モジュールには、ビットコインやリップルへ接続するメカニズムなどの基本的な機能を含んでいます。それらは標準のオークション、エスクロー、約定の実行等のより高度な機能も含むことができます。その論理はおそらくは多くの独立した当事者達に広く利用され、実証されています。
コディウスは複数の契約により共有され、インポートすることができるハッシュ値により特定されるモジュールを利用しています。

コード・サンドボックス
スマート・オラクルの概念の中心は、ユーザが契約のコードに合意し、さらにそれを信頼される第三者あるいはそれを実行する当事者へアップロードする能力です。スマート・オラクルは、信頼されないか実際に悪意のある場合があるユーザ・コードを安全に実行することができなければなりません。オラクルはそれら自体のシステムとそれらが実行するその他の契約の完全な状態を保護しなければなりません。
信頼されないコードのサンドボックス、あるいは機能の制約のために最も広く言及される四つの方法は、以下に説明されています。様々なスマート・オラクル・システムはこれらのオプションの別個の部分集合を利用することを選択する場合がありますが、それらはセキュリティを増すために層状に共に配置することができます。本節の最後に、四つの方法を共に討議し、コディウスのためのグーグル・ネイティブ・クライアントを私達が選択することについて説明します。

1. 仮想マシン(VMs)
仮想マシン(VMs)とは単独の物理的マシンの内部で独立したコンピュータが競合する環境です。サーバあるいはコンピュータは複数のVMsを実行でき、各々はそれ自体の完全なオペレーティング・システムを持っています。最も現代的な実行においては、VMのセキュリティはコンピュータのプロセッサの仮想命令セットに依存しています。VMと外部世界あるいはホスト・マシン間の通信はハイパーバイザーとしても知られる仮想マシン・モニタにより厳密に管理されます。
VM技術は1960年代に遡り、現在コードのサンドボックスのために広く利用されています。ほとんどのクラウド・コンピューティング・プロバイダは、サーバごとに複数のユーザのコードを実行するためにVMsを利用しています。VMsはコードをサンドボックスするためのより安全な方法の一つかも知れませんが、そのマイナス面はそれらがコンピュータ資源の観点で比較的費用がかさむことです。各インスタンスには完全なオペレーティング・システムを含んでいるので、一つの契約を実行する度に一つを起動する時間とエネルギーが多くの契約には実際的ではありません。それにもかかわらず、オーナーがより安全な実行環境により多くの費用を支払う用意がある高価な契約のためのオプションとして、ホストはVMsを提供することを選択する場合があります。

2. オペレーティング・システム保護ドメイン
保護ドメインあるいは「リング」は多くのプロセッサ・アーキテクチャ、特にx86に組み込まれています。それらは一般にオペレーティング・システムによって使用され、それにより相互から、あるいは基礎的なハードウェアに対するアクセスから個々のプロセスを分離することが可能となります。究極的に保護ドメインに依存するセキュリティ技法には、プロセスに基づく隔離(process-based isolation)、FreeBSDジェイル(jails)、linuxコンテナ(LXC)、SELinux,AppArmor及びさらに多くを含みます。
Dockerなどのコンテナ・システムはソフトウェア開発のために従来のVMsに対して急速に人気を得ています。なぜならそれらは起動が軽く素早いからです。しかしながら、これらのコンテナは信頼されないコードに対するサンドボックス技法としては十分に安全ではありません。
このモデルの下では、すべてのセキュリティはホストのオペレーティング・システムの優先権のある層を強制する能力に依存しています。これはカーネル内のバグはサンドボックスの悪用につながる場合があることを意味しています。さらに、人気のあるオペレーティング・システムのカーネルのほとんどは非常に大きな攻撃表面を提供しており、より小さな信頼されたコードの基盤に依存するサンドボックスに比べて、それらのセキュリティを保証することを根本的に困難にしています。それは、保護リングやプロセスに基づく隔離などのオペレーティング・システムに基づく機能は、追加のセキュリティのためにその他のメカニズムと層状に配置されなければならないことを示しています。

3. ソフトウェア障害隔離
ソフトウェア障害隔離(Software Fault Isolation(SFI))は、マシン・コード・レベルでの減少された命令セット、あるいは拘束される可能性のあるコマンド・セットに対するコンパイル・ソフトウェアに依存します。サンドボックスは、許可されたセット以外のいかなる作用をも含まないことを保証するために二進数を静的に検証することにより、その規則を強制することができます。
SFIはサンドボックスの魅力的な形態です。なぜなら、検証機構が唯一の信頼された構成要素であるので、非常に少ないコードを使用して実行されることができるからです。これにより最小の信頼されたコード基盤をもたらすことができ、それによりシステムが検証するのを容易にし、それゆえにより安全になる傾向があります。

4. 能力に基づくセキュリティ
能力に基づくセキュリティは、プログラムが利用することを意図されていない機能や資源への参照すらできないデザイン原則です。それは「英語の表現能力を制限することにより個人的思想を除去する」ことを目指している、オーウェルの1984年からの「ニュースピーク」と類似しているとして最も簡単に理解されています。あなたは非合法な思想を表現するための言葉すら持っていなければ、あなたは法律を違反することができません。プログラムに対するその原則が類似しています。
スマート・コントラクト・システムは、契約が指定された能力に基づく言語で記述されることを要求することにより、信頼されていないコードをサンドボックスすることができます。プログラム言語Eはすべての資源が偽造不可能な能力トークンを使用してアクセスされることを要求するように特別にデザインされました。ジャヴァスクリプト(JavaScript)等の翻訳された言語は、根本的に類似の原則を使用しています。:その言語はブラウザの中でウェブAPIs等のようなあるクラスと機能だけをエキスポーズします。あるシステムはこれらの同様の性質を持つ独立したカスタム言語を実行することもできます。あいにく、能力に基づくセキュリティが使用されている唯一のサンドボックス層である場合、すべての契約オーサーはこの環境外部で広く使用されていない単独の言語を使用することを強制します。

コディウス及びグーグル・ネイティブ・クライアント
グーグル・ネイティブ・クライアントは、ほとんどのコンピュータ・プロセッサにより使用される低水準のコマンドである、信頼されていないx86コードを実行するためのサンドボックスです。ネイティブ・クライアントは、ウェブサイトが通常限定さているHTML/CSS/ジャヴァスクリプト(Javascript)に反して、ウェブ上でコンパイルされた二進数コードを実行するために開発されました。ネイティブ・クライアントは、ユーザを潜在的に悪意のあるコードから保護する束縛された実行環境を提供するために、ソフトウェア障害隔離(上記)の上部に数多くの改善を成しています。
ネイティブ・クライアントはいかなるプログラム言語をも実行するために使用され、現在C、C++、Python、V8 JavaScript、Ruby、Go、Mono及びLuaをサポートしています。最近のネイティブ・クライアントのバージョンはx86-32及びx86-64アーキテクチャ並びにARMとMIPSをサポートしています。グーグルはネイティブ・クライアントをその他多くの中でHangouts Video及びQuickOffice等の計算に集中したウェブ・アプリや、ChromeOSアプリや信頼されていないコードをホストするデータセンタのために利用しています。最新のベンチマークは、ポータブル・ネイティブ・クライアント・モジュールがLLVMによりコンパイルされたネイティブ・コードよりもわずか10-25%遅い速度で実行することを示しており、それゆえにネイティブ・クライアントは始動するのに効率的なだけではなく、パフォーマンスの高い実行を提供します。
コディウスはセキュリティ、パフォーマンス及び柔軟性の比類のない組み合わせを提供するので、ネイティブ・クライアントを利用しています。
ネイティブ・クライアントはVMよりも軽量で、すべてのオペレーティング・システムが管理するコンテナよりもはるかに小さな攻撃表面を提供します。VMs及びコンテナは将来より良いパフォーマンスとセキュリティのバランスを発展させるかもしれませんが、それらは現時点では私達の要件を満たしてはいません。
私達は、契約が特定の能力に基づくプログラム言語で記述されることを求めることが、そのシステムの採用をむやみに阻害してはいないことを主張します。むしろ一部のオーサーやホストがカスタム言語や能力に基づく言語で記述された契約を好む場合、ネイティブ・クライアント・サンドボックス内部でそのように実行することもでき、さらに別のセキュリティ層を提供するでしょう。
ソフトウェア障害隔離及びネイティブ・クライアントは、すべてのプログラム言語をサポートするに十分な柔軟性を持ち、既に開発され、広く使用されているモジュールの再利用を可能とする一方で、最小の信頼されたコード基盤に依存しています。

契約APIs
スマート・コントラクト・コードはサンドボックスされ、その機能は制約されていますが、スマート・オラクルは、それらが実行する契約に対する特定のAPIs(アプリケーション・プログラミング・インタフェース)を公開することを望みます。契約の機能に関するよりきめの細かい制御能力を与えるために、コディウスの契約オーサーは明示的にどのAPIsにそれらがアクセスできるべきかを指定します。
契約ホストはそれらが選択するいずれのAPIsをも開発し、公開することができますが、私達は外部APIsに渡るサンドボックス内部のコードを強調するアプローチを一般に主張します。APIsは複雑な機能の構成要素でありますが、それらはスマート・オラクルの信頼されたコード基盤の一部と成らなければなりません。他方モジュールは容易に開発され、特定の契約のために含められ、ホストには統合されません。
以下に私達は、スマート・オラクルが提供することを期待する幾つかの中核のAPIsとコディウスが提供するであろうものを説明しています。

特有の秘密鍵対
契約の主要な性質の一つは、それが暗号化されたアイデンティティを持つことです。特に、契約のインスタンスを実行するには、契約当事者に対して、特定の契約ホスト上で実行する実際に特有で特定されたコード基盤であることを証明することができなければなりません。
先の節において私達は、コードのハッシュ化に当事者達がどのように合意できるかについて取り扱いました。このハッシュ化を特定のホストで実行する与えられたインスタンスと連携させるために、このホストは各契約と公開鍵の署名のための特有の暗号鍵対を生成しなければなりません。

エントロピー(乱雑さ)
多くの契約用途の事例は暗号法を必要としています。暗号法の基本要素はサンドボックス内部で実行することができる(サンドボックスが十分に効率的であることを想定し)一方で、多くの暗号化プロトコルはエントロピーの良い供給源あるいは乱数値を必要とします。それゆえ、スマート・オラクルは、ホストが暗号化されたアプリケーションに対して十分安全であると見なすエントロピーを取得するために、APIsを提供しなければなりません。

インターネット
オラクルの古典的用途は、現実世界と相互作用させること、及びスマート・コントラクトに対してその状態に関する情報を提供することです。一般にこれは、インターネットを介したサービスと相互作用することを意味します。HTTPサービスはおそらく最も断然興味深いですが、私達はトランスポート層(OSI層4、例えばTCP/UDP)よりも高いAPI能力を制限する理由を見つけることができません。これはHTTP、SMTP、さらにビットコインやリップル等のいずれのアプリケーション層プロトコルも、単純に外部への直接的トランスポート層コールを実施することにより、サンドボックス内部から利用されることを意味します。
コディウスはTCPとUDPのためにAPIsを提供します。現在、私達は契約が短い実行時間のプログラムであると想定しているので、外向きのソケットのみが許可されています。しかしながら将来的には同様にイベントを聞き、処理するための機能も存在するでしょう。(要求が到着するまで契約が中止される等。)

ファイルシステム
契約の複雑さが増すにつれ、この複雑さを管理する必要性も増します。各契約を単独の二進数あるいはソース・コード・ファイルへコンパイルすることは可能であるかもしれません。しかしながら、契約がアクセスできる仮想ファイルシステムを実行することはより有意義です。これは契約に静的データをバンドルする方法を提供します。コディアスの契約には、スマート・オラクルがアクセス制御を強制できるようにリンクされた、いずれかの静的ファイルのハッシュ値を含まなければなりません。
ファイルシステムAPIはモジュールを含める機能とはわずかに異なっていますが、正確な実行は同様であるかもしれません。モジュールを含めることにより、契約は他者が記述し、完成しているコードの複製を回避することが可能となります。仮想ファイルシステムを持つことにより、契約オーサーは彼らのプロジェクトを論理的な方法で構成することが可能となります。さらに、多くの通常のコード・プロジェクトやユーティリティはファイルシステム・コマンドを使用して、競合するその構造が既存のプログラムをサンドボックスへ非常に容易にポートできるように記述されます。
私達は一部のローカルな記録設備の利用を望む契約も予想しています。ファイルシステムに書き込みアクセスを提供することは賢明ではないように思われますが、ウェブ・ブラウザのローカル記録に相当するものは利便性が高いことを実証しているかもしれません。

時間
正確な時間情報へのアクセスを持つことは、いずれの計算プラットフォームにとっても役に立つ能力です。例えば、時間に基づくワンタイム・パスワード(TOTP)等の一部の暗号化アルゴリズムは正確な時間の参照を必要とします。
高度に正確なクロックは、グーグルのSpanner等の分散データベースにも、これらをより効率的、公正で正確するために使用されます。グーグルはGPSと原子時計を運用しています。なぜならこれらの装置は安く購入及び運営できる一方で、非常に正確なタイミング・データを特に一緒に使用した場合に提供できるからです。私達は、契約ホストに彼らが点呼できる最も正確なクロックを使用したタイミングAPIを提供することを推奨します。

追加のAPIs
私達は前述のAPIsがほとんどのスマート・オラクルにより利用可能とされることを期待しますが、これは可能性の完全なリストではありません。スマート・オラクルはカスタマイズされたAPIを提供及び開発するAPIsのセットを定義することができます。しかしながら先に言及されたように私達は、APIsは構成要素と考えられるべきであり、他方再利用可能なモジュールはより複雑な機能を備えるための主要なメカニズムであるべきだと主張しています。
このシステムはビットコインとリップルにより触発されましたが、いずれの特定の分散ネットワークとも独立しており、これらの種類のネットワークと相互作用することに限定されてすらいない事実を私達は強調しなければなりません。

契約ホスティング
単独(信頼された)ホスト・モデル
スマート・オラクルの最も基本的な実行には、一つのオラクルのみが関連します。オラクルはコードを適切に実行することが信頼されており、参加者は契約が管理する何らかの資産が消失したりせず、いずれかの契約当事者との共謀がないという確信を持つに違いありません。
今日、多くの会社は企業や個人のためにコードの実行を提供しており、それらはそれを実行することを信頼されています。単独の信頼されたホスト・モデルは、インターネット・ホスティング・サービスとサービスとしてのソフトウェア・プロバイダ(SaaS)に類似しています。私達は、単独のホストを利用したセキュリティが十分であり、そのような構成の単純さがそれを魅力的なオプションとする多くの用途事例を予想しています。
スマート・コントラクトがそれらの成果を検証可能な方法で発行するために、スマート・オラクルは各契約に特有の公開鍵/秘密暗号鍵を供給する傾向があります。オラクルでは、各スマート・コントラクトがそれらのシステムで実行する特定の契約のインスタンスのために特に公開鍵/秘密暗号鍵対を生成したことを公に主張するトークンに、暗号化された署名をすることができます。スマート・オラクルは、契約当事者がこれらの署名を検証することができるように、良く知られた、あるいは容易にアクセスできる公開鍵を持っています。単独のホスト・モデルでは、契約はその他の集中されたウェブ・サービスのためにAPIキー等の共有された秘密の値も与えられます。契約はこれにより暗号化された署名の代わりにAPIキーを利用して、その結果を報告し、あるいは何らかの種類の取引を開始することができます。

複数(信頼されていない)ホスト・モデル
単独ホスト・モデルは非常に多くの数の用途事例に適切であると思われますが、高い価値や低い信頼が関連するシナリオは複数のホスト・モデルによって取り扱われるのが最適でしょう。このモデルでは、契約コードは幾つかの数、例えば10個の独立したスマート・オラクルへ分散されます。閾値は、それらのオラクルの幾つかが契約の成果を実現するために、その結果に合意しなければならないように設定されます。例えば、最大3つのオラクルが悪意のある挙動を示し、あるいはオフラインであり、さらに契約の実行に影響を与えることなくハックされても許容される10中7のスキームを利用することができます。これは単独のホスト・モデルよりも構成するのにより複雑で費用がかさみますが、そこには潜在的障害個所が一つも存在しないので、より良いセキュリティ保証を提供します。実際には、複数ホスト・モデルは以下に双方とも説明される暗号化された複数の署名、あるいは閾値署名を利用して実行される傾向があります。

複数署名
複数署名スキームには、元来の実体の特有の数の署名が存在する場合のみ、その結果が有効であると見なされるような、少数で単独の事前に決定された署名する複数の実体が関連します。複数署名を利用するように構成されるスマート・コントラクトは、独立したスマート・オラクル上で実行され、各インスタンスは特有の公開鍵/秘密暗号鍵対を与えられます。単独ホスト・モデルと同様に、各スマート・オラクルはそのシステム上で実行する特定の契約に対する特有の暗号鍵対である事実を公に証明します。契約のインスタンスは、各々それらの署名を幾つかの中心的実体へ送信するか、あるいはそれらをどこへでも公に発行します。
現在、ビットコインのスクリプトは複数署名で管理されるアカウントを有効にしており、リップルの複数署名サポートは開発中です。ビットコインあるいはリップルのアカウントの契約は、契約がそれらの資産に排他的な管理権を持つように、多くのスマート・オラクル上で実行する契約インスタンスの暗号鍵対により合同して管理されるために構成されています。複数署名のマイナス面は、署名を検証することがビットコインやリップルの取引検証ツールにとって比較的費用がかさむ作業であり、それゆえ単独の取引により多くの署名を追加することはより高い取引手数料へつながることです。それにもかかわらず、このモデルの利点はすべての契約がお互いに独立した成果を作り出すことができ、署名は究極的に資金の管理権を「勝ち取った」契約当事者等の別の実体によりほとんど労力を要せずに収集されることが可能です。
あいにく、より多くのホストがそのスキームに参加すると、より多くの署名が提出されなければなりません。これは分散コンセンサス・ネットワークにとっては特に重大であり、すべての検証ツールはすべての署名を検証しなければなりません。この理由により、ほとんどのコンセンサス・ネットワークは署名の数あるいは署名者の数に制限を導入しています。例えば書き込みの時点で、ビットコインは標準の取引に最大15の署名者を許可しています。
この問題を取り扱うために、閾値署名スキームは魅力的なオプションです。なぜならそれらは、どんなに多くの当事者が署名に参加していても、単独の有効な署名に帰結するからです。私達はそれらについて次の節で説明します。

閾値署名
閾値署名は複数の別個の署名を数学的に組み合わせることにより計算される署名です。様々な閾値署名スキームは、使用される精密な閾値のために様々な水準のカスタマイズ性を許容していますが、一部は任意の閾値をサポートしています。共有の秘密暗号鍵は決して再作成されませんが、むしろ独立した署名の断片が別々に計算され、その後特定のデータの一片のために単独の署名に統合されることに注意することは重要です。
(EC)DSA署名に対して
閾値楕円曲線デジタル署名アルゴリズム(The Threshold Elliptic Curve Digital Signature Algorithm)は、ビットコインやリップルの他多くで利用されている種類のECDSA署名をイブラヒム、M.Hら(Ibrahim, M.H. et al)(2003年)とゴールドフェダーら(Goldfeder, et al)(2014年)により合同で生成するために説明された方法です。そのアルゴリズムは、いずれの当事者も他者の秘密の値について何ら知ることができないようにデザインされています。生成される署名は通常のECDSA署名と見分けがつかず、それゆえビットコイン、リップル及びその他のシステムで何ら修正を加えることなく直ちに機能します。そのマイナス面は、現時点でのそのアルゴリズムの最高のバージョンは、当事者の総数nが、セキュリティ閾値をtとした場合最小でも2t+1であることを求めることです。これは任意の閾値のスキームを不可能としています。さらに、このアルゴリズムは複数当事者の計算を利用しており、そしてそれは、契約インスタンスは署名を生成するためにはお互いを知っており、通信する必要があることを意味しています。

(EC)Schnorr署名に対して
Schnorr署名アルゴリズムは、独立して生成された複数の署名の構成物を一つにすることが可能なスキームの例です。各署名実体、スマート・オラクルの一つで実行する契約インスタンスは、それらの署名を生成し発行することができます。別の実体は、署名の各割り当てを検証することができ、充分な数が存在する場合にはそれらを構成することができます。OpenSSHは、最近Ed25519と呼ばれるSchnorr署名の特定の種類に対するサポートを追加し、リップルは現在この署名アルゴリズムに対するサポートの追加を検討しています。あいにく、ビットコインはEd25519をサポートしておらず、それゆえにこの特有の閾値スキームは現在それと互換性がありません。それにもかかわらず、Ed25519は構成可能で、柔軟な閾値署名のための効率の良いアルゴリズムを代表しており、それゆえ私達は複数ホストのスマート・オラクル・モデルと連携して使用されるのに良いスキームであると信じています。

課金
スマート・オラクルの最も柔軟な部分の一つは、契約当事者が契約の履行のためにスマート・オラクルにより支払うことを可能とする課金システムです。課金システムは中核のシステム・デザインから完全に分離されており、それゆえにスマート・オラクルはクレジット・カードからビットコインに至るまで、彼らが選択するいかなる支払方法でも受け入れることができます。前払いあるいは事後に課金される費用を要求する決定も、オラクルの管理者の判断に完全に委ねられます。
フォールト・トレランス
スマート・コントラクトが提供することを目指す幾つかの保証には以下の事を含みます。:
正当性 ? コードが記述された通りに誠実に実行される。
可用性 ? いつでも契約と相互作用することが可能である。
機密性 ? 開示されることが明示的に意図されていない値は開示されない。
スマート・オラクルに対する私達の提案は、フォールト・トレランスのために特定のアルゴリズムが利用されることを命令しておらず、フォールト・トレランスの水準は完全に契約に依存することを意味しています。
私達の分析のために、私達はtを閾値とし、nを契約ホストの総数とする閾値署名スキームを使用した契約例を仮定します。閾値t *は1よりも大きく*nよりも小さくなければなりません。署名を作成するためには、t+1の署名者が必要となります。私達は、契約ホストに対するすべての要求は幾つかのクライアントによって開始されるものと仮定します。私達は、各クライアントがそれ自身の要求が成功することを望んでいると仮定します。
そのような契約は最大tの障害に対して正当性の保証と、最大(n – t) ? 1の障害に対して可用性の保証、及びフォールト・トレランス(障害許容)の無い機密性の保証を提供します。

機密性
強力な機密性の保証が必要とされる場合、当事者には幾つかのオプションがあります。彼らは契約の部分を区分することを選択し、各部分に対して異なるセットの契約ホストを利用することができます。この事例においては、契約の様々な部分間の関係を隠すためにブラインド署名を利用することが可能です。
別のオプションは、契約ホストが管理している実際のデータを彼らから隠すために、準同型暗号及びゼロ知識証明等の暗号化技法を利用することです。
最後に、多くの事例において当事者はオフライン契約の利用を選択することができ、そしてそれは争議が生じない限り、彼らはいかなる情報も、いかなる契約ホストに対しても漏らしてはいけないことを意味しています。オフライン契約の節を参照してください。

契約クライアント
スマート・コントラクトへの彼らの参加を管理するために、当事者は彼らの側の契約ホストと相互作用を実行するソフトウェアを必要とします。
多くの契約モジュールに対して、私達は対応するクライアント・ソフトウェアが存在することを期待します。用途事例に依って、このソフトウェアは優雅なグラフィック・ユーザ・インタフェースから最も基本的な要素のコマンドライン・ツールに至るまで、非常に様々な性質を持っている場合があります。この白書の目的のために、私達は契約オーサーが適切なクライアントあるいは指令を、サード・パーティー開発者が既存のクライアントを契約と相互作用させることができるように提供することも仮定しています。

オフライン契約
現在の法律上のシステムでは、ほとんどの契約は「オフライン」で完結します。すなわち法律上のシステムが発動することがありません。当事者が合意された条件に固執するよう動機付けされるのは法律上のシステム発動の脅威です。
スマート・コントラクトの領域では、オフライン契約も可能であり、有益です。当事者はこれらの行に沿ったプロトコルに従います。:
合意された条件に違反する場合に、各当事者に対して罰則を伴う契約を作成する。
契約コードの末尾に乱数値を付加する。これはコードのハッシュ値から契約の詳細についての何らかの知識を取得する際に処理しにくくする。
契約が契約ホストあるいはホストらから受け取るであろう公開鍵あるいは鍵対を要求するが、実際の契約はアップロードしない。
エスクロー化された資金あるいは当事者の資産を管理するその他の何らかの形態の権限への公開鍵によるアクセスを付与する。
当事者はここで互いにオフラインでの相互作用へ移行することができる。
いずれかの当事者が他のいずれかを騙した場合、被害者は契約をアップロードし、契約違反の罰則を科すためにそれを実行することができる。
いずれの当事者も騙さない限り、契約は決してアップロードされず、実行されることはない。一部の人は以下のことに言及しています。:
当事者は他者が騙す場合に実際に契約をアップロードし、罰則を科す信頼できる脅威を作成しなければならなりません。やはり、これは現在の法律上のシステムに類似しており、そして当事者が訴訟を起こす場合があるという説得力のある脅威を持たなければなりません。一つの差異は、スマート・コントラクトでは「訴訟」は安く(ほぼ無料)、素早く(ほぼ即座)、予想可能な結果がもたらされます。
言及されたように、この種類の契約は争議の事象を除き、契約を実行する費用を回避することができます。これは契約ホストがどのようにお金を稼ぐのかという疑問を提起するかもしれません。私達は二つの方法を考えることができます。:
契約ホストは争議からお金を稼ぐ。
契約ホストは公開鍵の発行からお金を稼ぐ(上記ステップ3を参照)。
アイデンティティに基づく暗号化を使用して、あるいは同一のホスト上のすべての契約に共通の暗号鍵でメッセージへの署名を可能とすることによりステップ3における要求を回避することができます(但し、メッセージにある制約を課す。例えば契約のハッシュ値を含む特定の形式に固執したメッセージを強制するなど)。そのような機能を提供するか否かは契約ホストの選択次第です。

金融上のアプリケーションとその他
一般にスマート・コントラクトは、明確な条件と成果から構成されるいかなる種類の契約や関係をもモデル化するために使用されます。スマート・オラクルはその実行を簡単で、柔軟で強力にします。
以下に示したのは、私達が現在予想することができる幾つかのアプリケーションであり、およそ最も単純なものから最も複雑なものの順に並んでいます。そのシステムは非常に拡張性があるので、生態系が発展し、契約オーサーが常に増加するモジュール基盤や既存の契約の上に構築する時に、その機能はここから非常に拡張することを私達は予期しています。
価値ネットワーク間の橋渡し。ビットコインやリップルなどの分散ネットワークはアカウントやバランスを追跡する分離された台帳あるいはブロックチェーンを維持しています。従来の金融システムは同様にそれら自身の台帳を持っています。スマート・オラクル上で構築された契約は、異なるシステム間の自動的で信頼できる橋渡しを作成することができます。そのような橋渡しは一つのシステムで支払いを受け付け、直ちにバランスを発行し、あるいは別のシステムでの支払いを開始することができます。
エスクロー。スマート・コントラクトは二者間のやり取りをモニターするエスクロー・アカウントとして容易に構成されます。何らかの商品、資産あるいはサービスの買い手は契約アカウントへ支払いを送付します。その契約はドメイン・ネームのWHOISレジストリや不動産購入の公共の家屋所有者記録等の外部サービスを監視します。所有権が売り手から買い手へ譲渡された時に、その契約は自動的に資金を売り手に解放します。
暗号化通貨ウォレット管理。現在ビットコインとリップルは、売り手が買い手の代わりにクレジットやデビットカードが実施するように支払いを開始することができる、支払いの引き出しを可能とする良いメカニズムを持っていません。契約により管理されるウォレットは、日々の引き出し制限から特定の実体に対するアクセスの許可及び拒否等の、多くの様々な種類の複雑な管理を含むことができます。これは予約代金と条件付き支払い、秘密暗号鍵を開示することの無いウォレットへのアクセスへのきめの細かい管理を可能とします。
デジタル資産のオークション。スマート・コントラクトは、デジタル資産あるいは権利の所有権が与えられる場合、労力を要せずにオークションの規則を実行することができます。ビットコインやリップルなどのネットワークでの支払いを入札として受け入れ、落札者以外の入札すべてを返金するように構成でき、あるいは署名された取引は直接契約コードにより記録され、落札者の契約のみが実行依頼されるように構成することができます。
デリバティブ。デジタルあるいは非デジタル資産の成績を監視する契約は、先物取引、先渡し取引、スワップ取引、オプション取引等にも使用することができます。
債券及び株式。事前に定義された規則に従って実行される支払いと権利に基づくその他の有価証券もスマート・コントラクトとして記述されることができます。
スマート資産。スマート資産の伝統的な例は、誰が所有者であるかを転送可能で偽造できないデジタル・トークンに基づいて知ることができる乗用車です。契約は所有権の譲渡とそれに伴う規則を管理するように構成することができます。これにはその他の契約の担保として、その資産の一時的委任と潜在的利用を含みます。
投票。将来において、スマート・コントラクトは民主的、官僚主義的及びその他の種類の資産や組織における管理構造の執行のために利用することができます。その他のすべてのアプリケーションと同様に、その契約は契約自体のコードの修正の規則までも含め、事前に定義された規則を執行します。多くの非金融上のアプリケーションはより複雑なインフラストラクチャーとより発展した生態系を必要とし、それゆえ私達はこれが構築されるにはしばらく時間を要すると予期しています。

結論
スマート・コントラクトは技術、ビジネス及び法律にとってわくわくするような新たな未開拓な分野です。私達は、この本誌と私達の実行がこれらの概念を実現する上で貢献することを望んでいます。
スマート・オラクルはサンドボックスするコード実行環境と、実世界の情報を提供するオラクルのアイディアを組み合わせています。ビットコインとリップル等の既存の分散ネットワークとは独立しており、すべての分散コンセンサス・データベースを含むいかなるインターネットに基づくサービスとも相互作用することができます。分散ネットワークから信頼されていないコード実行を分離することは、複雑さを減少させ、それゆえに双方のシステムのセキュリティを増加させます。
コディウスの実行には信頼されていないコードをサンドボックスするために、グーグル・ネイティブ・クライアントを利用しており、それにより開発者がいかなるプログラム言語でも契約を記述できるようにしています。契約とモジュールを安全に特定するために、決定論的コンパイル、ハッシュ化及び署名されたキーを使用します。私達は低い信頼あるいは高い価値のシナリオに対して、複数の当事者の署名が計算を分散する方法を提案しています。
コディアス及びスマート・オラクルは一般に開発者、起業家、企業心のある法務及び財務専門家に新たな可能性を開拓しています。長々とした法律上の契約を以前は必要とした契約は、コードに翻訳されスマート・オラクルにより自動的に実行できます。スマート・コントラクトは人々により公正で、より入手可能で、より効率的な法律上のシステムを構築する権限を与える可能性を秘めており、スマート・オラクルはその夢を叶える最も単純な方法の一つです。
仲間に入りませんか。コミュニティーに参加下さい。www.codius.orgを訪れてください。