-
Notifications
You must be signed in to change notification settings - Fork 28
[Japanese] Codius White Paper (コーディウス )
Stefan Thomas, Evan Schwartz — [email protected]
私達が紙の世界に生きていることを、現在の機関は当然だと思っている。私達は紙に書かれた契約、法律、を公的な関係だとしている。 スマートコントラクトは、それらの強いられているトランザクションのコストを削減することが出来る。 契約交渉における、検索、交渉、コミット、実行、判決、それらのステップが、スマートコントラクトの領域を構成する内容だ。
- Nick Szabo, [Formalizing and Securing Relationships on Public Networks (1997)]より(http://szabo.best.vwh.net/formalize.html)
スマートオラクルはシンプルで柔軟な方法で、スマートコントラクトを実装する。スマートコントラクトはビジネスのロジック、法律、その他のルールをエンコードするものが。 スマートオラクルは、スマートコントラクトに対して外部の世界の情報を提供するオラクルのアイディアの上に出来たものだ。 そしてコードを実行するコントラクトとともに情報を集める。 そのようなシステムでは、いかなるプログラミング言語において書かれたルールであっても、 他のサービスが暗号的に署名したコマンドを受け付けるどのようなサービスあっても、 コントラクトはやり取りを行うことが出来る。 このことを含めて、しかし限ることなく、暗号貨幣のネットワークが含まれている。 我々はスマートオラクルの実装を紹介する、これを[コーディウス]と呼ぶ。(http://www.codius.org) (based on the Latin “ius” meaning “law”),そしてコーディウスでは、コードのサンドボックス化のために Google’s Native Clientを使用する。
この文書においては、スマートコントラクトの背景と定義から始まる。 ここにおいて、スマートオラクルに対しての提案を始め絵、いくつかの技術的な実装方法の詳細を延べ、そしてセキュリティ面での問題を述べる。 そして最後のセクションでは、いくつかの金融的、非金融的なアプリケーションを紹介し、 全体としてのスマートコントラクトに、対する大きな可能性を紹介する。
Cornell Legal Information Instituteによるとコントラクト(契約)はこう定義される:
法律によって強制可能な義務を作り出すことに対しての合意。 基本要素は、お互いの合意と、契約で動く金銭的対価と、許容条項、そして法的条項。 例えば結果として引き起こる損害、依存する損害、そして特定の事項を含む契約を破ったことに対する損害に対して、法律的に可能な償いの条件だ。
スマートコントラクトは形式的にはある種の条件とその結果をコーディングしたものだ。 コードは契約当事者によって事前に合意されたもので、利害関係の無い中立的な機関によって、誠実に執行されなければならない。
The three key steps in developing and utilizing a smart contract are: スマートコントラクトを開発し、利用する中で3つの重要な段階は下記となる。
-
契約条項をコードに翻訳すること。 デジタルのシステムは決定論的であるため、コントラクトの出力の全ての可能性は明白に定義される。例えば、契約不履行や、（非決定論的な）仲裁者についてだ。
-
実行される、まさにそのコードに対して合意する必要がある。実際には、当事者は広く使われていて、設定・編集可能なコントラクトの モジュールを使うこととなる. 一旦実行されるコントラクトが合意されれば、合意されたそのコードが最終的に実行されるかの保証が極めて重要となる。 こちらのセクションを見て欲しい決定論的なコンパイルと、ユニークな秘密鍵の組
-
コードの実行は信頼出来る方法で行われる。コードは不可分な第三者もしくは、独立した共謀する可能性が極めて低い団体によって実行されなければならない。スマートコントラクトは、実際にコードが実行されることなしに、扱われることが出来る。オフラインコントラクト一層の詳細は、このユースケースに付いて見て欲しい。
伝統的な契約に変わって、スマートコントラクトを使うことによる究極的なメリットは、スピードと効率化、 そしてコントラクトがまさに合意したとおりに実行されることに対する信用からもたらされる。
いくつかのスマートコントラクトのシステムは、Bitcoin上のシステムも含めて、厳密に決定論的だ。 そのため、実世界とやり取りするためには、このようなシステムは「オラクル」と呼ばれる外部のシステムから渡される暗号による署名に依拠する。
オラクルは世界の状態に対する情報に署名する信頼されたエンティティである。何故なら署名の確認は、決定論的に行うことが出来、これによって、決定論的なスマートコントラクトは、決定論的でない外部の世界からの情報に対して、作用を返す事が出来る。
このセクションでは下記の定義に従う、スマートコントラクトについて説明する、 ここで「スマートオラクル」と、「コントラクトホスト」を 互換性のある用語として使っていることに注意して欲しい。 この提案の中では、コントラクトのコードを実行するホストは、 外部世界に対しての情報とともに、 外部のシステムを稼働させるコントラクトを提供するために設置されただけかもしれない他のシステム内のオラクルと同様である。
契約当事者はスマートコントラクトを協定を実行するために使おうと合意した個人と法人である。 他の関係する、だがはっきりと異なるかもしれないエンティティは、コントラクトの執筆者と、所有者だ。 コントラクトの執筆者はコードを書いた人ではあるが、特定の協定に対しては全く関係することが無い。 例えば、執筆者はオープンソースのオークションのコントラクトを公開している個人又は団体の開発者であり、 コントラクトの所有者は、スマートオラクルによって執行される。hor could be a developer or group of developers that have published an open source auction contract. The contract owner is the entity that sets it up to be executed by the smart oracle(s).
コントラクトのホストはコントラクトの契約当事者や、利害関係のある人間であるべきでないことに注意して欲しい。
公開鍵/秘密鍵による暗号化は、メッセージが暗号化され、ランダムに見えるな文字列へと変換されることを可能にする。 メッセージが公開鍵に依って暗号化されたとき、対応する秘密鍵を持っている者によってのみ、そのメッセージを復号し、解読することが出来る。
公開鍵/秘密鍵の暗号は、秘密鍵の保持者が暗号学的にメッセージに'署名'することを可能とする。 秘密鍵の保持者によって作成された署名のみを誰もが正しいものだと認める事が出来る。
公開鍵暗号は、スマートオラクルに対してのいくつかのよくある使い方を支えている、それゆえに非対称な暗号化と、暗号的な署名がどのようにして機能するかということに対しての基本的な理解に対して有用であるかもしれない。 更に背景を知るためには、Wikipediaの下記の文書を薦める。 public-key cryptography and digital signatures, and this simplified explanation of public key cryptography.
このスマートオラクルの文書は、全ての既存の配布ネットワークと合意のデータベースと暗号通貨から独立した内容であるが ビットコインとリップルによって打ち立てられた概念によって強く影響を受けている。 ビットコインを紹介すると、P2Pのネットワークでのデジタル通貨であり。 bitcoin.org. あらゆる価値を送るための分散形のプロトコルであるリップルについての詳しい説明はこちらにある。ripple.com.
スマートコントラクトとオラクルについての概念は以前から存在していた。幾つかの早い段階での仕様は(（Bitcoinも含めて)コントラクトをコンセンサスのネットワークの中で実行し、決定論的なコントラクトの実行が行われるというものだった。 この文書では、コントラクトの実行がスマートオラクルによって行われることが、システムを大きく一般化し、簡単なものにすることを示す。
スマートコントラクトの概念は、Nick Szabo によって広くもたらされた。彼は、1990年後半にソフトウェアとハードウェア内で形式化し、エンコーディングした関係性をつくることが、 ビジネスの論理と機能を簡単で安全なものにすると議論した。 彼は負債や所有権のような契約的な文書を埋め込むことについても文書を書いた。 Szaboは自動販売機を原始的なスマートコントラクトの先祖の例として用いてあげた、何故ならば自動販売機はハードウェアとソフトウェアがシンプルな契約的な合意を行うものであるからだ。 お金を入れた人はだれでもスナックを代わりに受け取るだろう、たとえそれがマシーンの所有者によって作られた明文化された契約でなくても。 Wei Deiは同じくデジタルの契約について、1990年代後半の彼のB-moneyという提案の中で記載した。そして、自己効力的で、暗号をベースとしたコントラクトはSzaboのアイディアと近いものだった。
最近になって、暗号通貨に対しての関心が高まるにつれて、再度スマートコントラクトについての関心も高まってきた。 数学を基礎とした通貨のネットワークがスマートコントラクトにとって重要な礎を築いた。 プロトコルの中での資産は、 ビットコイン や Ripple のように公開鍵と秘密鍵によって所持者が同定されるものがある。 アカウントの秘密鍵を行っている人のみが行えるトランザクションによって作られる暗号的な署名によって支払いが実行される。 スマートコントラクトはそのような暗号的な署名を作り出すことが出来、 そのようにして、どのような種類のデジタルアセットであっても、いくつか、もしくは1人の所有者を判定する。
不幸なことに暗号通貨の開発者は、強力なスマートコントラクトの言語と、頑丈なコンセンサスの両方を持ったシステムをつくるという 試練が分かってしまった。 Bitcoinのスクリプトでは、シンプルなロジックをbitcoinのネットワーク上でコードとして実行できるが、 しかしながらエンコーディングの進んだ論理と、信頼出来ないコードの実行は実装するのに一層の困難が伴うことが証明されている。
コンセンサスネットワークは、機能的に保守的なものでなければならない。なぜならネットワークの誰もが合意した変更については、変更と更新が難しいからだ。Bitcoin wiki ではこの問題について現況している。"クライアントソフトウェアが実装の際にバグを作ってしまうかも知れないため、幾つかの複雑なopcodesを使えなくした。もしバグがチェーンに含められてしまえば、、どのような修正を持ってしても、そのチェーンをフォークせざるを得なくなってしまうリスクがあるためだ。” ブロックチェーンや、分散形の台帳をフォークすることは多数の競合する状態をネットワークに作り出すことになるため、 コンセンサスに基づくシステムにとっては大変望ましくない結果を生み出す。
我々は強力なスマートコントラクトを安全で信頼出来るやり方で、 現在のコンセンサスに基づくのRipple や Bitcoinのようなネットワークの複雑さを増やさない形で、実装する可能性を議論した。
信頼出来ないコードの実行はコンセンサスのデータベースと、アセットの所有権の移管を追跡する他のサービスから切り離されるべきだ。 コントラクトのシステム、信頼出来ないコードの実行を可能にし、暗号的署名を通じてコンセンサスのデータベースとのやり取りを可能にする。 このような署名は既に現在のコンセンサスのプロトコルの中に何も編集を加える必要無く存在している。 コントラクトをコンセンサスのネットワークから切り離すことは、このトラクトが様々なネットワークと同時にやりとりが出来、同様に仮想的にあらゆる種類のオンラインサービスをともやり取りが出来るようになる。 これは、1つのスマートコントラクトがBitcoinや、Ripple、WebベースのPaypalや、Googleや、Ebay等その他のSSH,LDAP,SMTP, XMPPのようなインターネットのプロトコルともやり取りが出来るようになることを意味する。
もしコントラクトの実装が既存のシステムと切り離されたとしたら、どのようにしてコードは実行されるのだろうか。 ここにスマートオラクルが必要となる。
大半のスマートコントラクトに対しての提案は、コンセンサスのネットワークの内部にあるビットコインでさえも、 外部世界の情報を伝える外部の独立した団体に依拠している、ビットコインのコントラクトは"oracles" に依拠しているが、
スマートオラクルでは、この概念を先に進め、オラクルの手に依って信頼出来ないコードが実行される概念を考える。 このときスマートコントラクトは外部世界についての情報を提供する事が出来る信頼されている機関か、半分信頼されている機関であり、 そしてこのコントラクトの当事者が合意したコードの実行を行う。
スマートオラクルの実装方法は幾つかの異なる方法がある。 この大きな構想に対して一層の興味をもった読者の方は最後の3つのセクションOffline Contracts, Financial Applications and Beyond and the Conclusion へと読み飛ばして欲しい。
一旦コントラクトを結ぶ両者が、ルールをコードへと翻訳しなければならなかった彼らが制作した規則に合意した。 これは両者が提案されたコートを確認し、合意したものビジネスロジックをコントラクトがきちんと表してるかを確認することは致命的である。 同様に重要な事は、スマートオラクルにアップロードされたコードを簡単に認証することが出来、 既に確認した形と全く同じように出来る再実行できることだ。 これは決定論的なコードの生成、ハッシング、そしてモジュールと共にコードを再利用するきっかけである。
全てのコントラクトを持っている両者はその最終版の機会が実行できるコードが、全員が納得した論理であることを確認することに対して これによって、ソースコードは再利用可能なプロセスを通して機械語へとコンパイルされ、シェアされなければならないことを意味している。 interpreted languages にとっては、ソースコードを共有するだけで順分である。いずれにせよ、参加者がスマートオラクルによって実行される最終内容に納得しなければならないということはとても重要だ。
セキュアなハッシュによる暗号化は、合意したバイナリとソースコードを同定するのに便利な方法だ ハッシングによって、任意の量のデータのインプットを、短く決まった長さのストリングへとする操作であり、 実用的な使い方として、このハッシュをもちいてあらゆるテキストやデータを一意的に同定するために用いられる。
必ずしも強く必要なわけではないが、我々は名前空間の衝突に対しての耐久性があるハッシュ関数を用いることを薦める 同じアウトプットのハッシュをもつ2つのinputを見つけようとすることは、現実的に出来ることではないだろう。 同じハッシュをもつ、動作する2つのコードを作り出すことは非常に難しいだろう、それが、喩え 喩え、ハッシュ関数がsecond preimage resistantなものであったとしても。
しかしながら、もし誰かが同じハッシュを持つ2つの異なるコントラクトを作り出したときには、それは重大な問題を引き起こす。 それゆえに我々はsecond preimageかつ、名前空間の衝突に対する耐久性のある、ハッシュ関数を使用する事を薦める。
伝統的な契約では、良く"ひな形”を共有してきたが、スマートコントラクトでもそれは何も変わらない あらゆるスマートオラクルのシステムは、一定の形式の再利用したコードを用いようとするだろう。 それによって、便利であると同時にセキュリティも増加する。
様々なコントラクトは、広く使われているモジュールの上に作られる、比較的シンプルで簡単なロジックをもつだろう。 例えばBitcoinや、Rippleと接続するための基本的な機能を内包するモジュールである。 Escrowや、担保などの更に進んだ機能を含むものもありえるだろう。 それらのロジックは多くの独立した機関によって広く使われ、認証されるものとなるだろう。 Codiusは様々なコントラクトによって共有され取り入れられたハッシュによって同定されたモジュールを使用する。
スマートオラクルのコンセプトの核は、ユーザーがコントラクト上のコードに対して合意する事が出来、 そして信頼出来る第三者の機関にアップロードすることが出来、信頼する機関がコードを実行できることだ。 スマートオラクルは、ユーザーのコードを信頼する事はできず、そのコードは悪意のあるコードかもしれないが、 スマートオラクルは、安全にユーザーのコードを実行できなければならない。 オラクルは、自らのシステムを守り、実行している外部の他のコントラクトとの整合性を守らなければならない。
下記の4つがもっとも一般的な、信頼出来ないコードに対してサンドボックス化をするか、もしくは機能を制限するための方法となる。 異なるスマートオラクルのシステムは異なるオプションのセットを選ぶかもしれないが、 セキュリティの増加のために一緒のレイヤーに置かれても良い。 このセクションの最後には、我々は4つの方法をまとめて議論し、Codius のために我々が選んだGoogleのネイティブクライアントに対して説明を行う。
仮想マシーン環境は1つの物理的なマシーンの中で、分割されているいくつものコンピューターを動作させるための環境のことをいう。 サーバーか、コンピューターは様々なBMを起動することができ、それぞれのVMは単体で完全な動作環境を持っている。 もっとも最近の実装ではVMのセキュリティはコンピュータのプロセッサーの仮想化の仕組みに依拠している。 VMと外の世界とのやり取りや、ホストマシーンが仮想マシーンモニターによって厳しく管理されている、hypervisorとしても知られている。
VMの技術は1960年代に遡る。それはコードのサンドボックス化のために広く使われ大半のクラウドコンピューティングのプロバイダーは様々なユーザーがサーバーごとにコードを走らせられるようにするために仮想マシーン(VM)を取り入れた。VMは、コードをサンドボックス化するための最もセキュアな方法かも知れないが、不利な点としてはコンピュータの資源の面で、比較的ハイコストであるということだ。 1つ1つのインスタンスが完全なOSを持つため、1つのコントラクトを実行するために時間とエネルギーを必要とする仮想マシーンは、多くのコントラクトを実行するためには不向きである。 それにもかかわらずホストがVMを選択肢として選ぶかもしれないのは、所有者がより一層安全な動作環境のために費用を払おうと思うような 高価なコントラクトの選択肢としてVMがホストに選ばれるかもしれないからだ。
保護されたドメイン、いいかえると、"rings"は有名なx86のような多くのプロセッサーの構造の上に立てられている。 保護されたドメインは一般的にOSによって使用され、他のプロセスや、ハードウェアに対してのアクセスから独自のプロセスを孤立させることを可能にしている。完全に保護されたドメインに依存するセキュリティの技術は、プロセスベースの孤立化を含み、FreeBSDや、jailsや、Linux Containers(LXC), SELinux, AppArmor など様々なものがある。
Dockerのようなコンテナシステムは、急速に 有名になった 。 何故ならば軽量で直ぐにスタートが出来るためだ。しかしながらコンテナは十分なセキュリティを持たない。 しかしながらコンテナは信頼出来ないコードをサンドボックス化するために使われることとなるだろう。
このモデルにおいて、全てのセキュリティはオペレーティングシステムが特権的なレイヤーを強制できるかどうかの能力に依拠してしまう。 このことはカーネル上のバグがあった場合には、サンドボックスが破壊されることに繋がるかもしれないことを意味する。 更にいえば、最も有名なカーネルが大きな攻撃の表面を作ってしまっていることは 小さな信頼できるコードベースに依存するサンドボックスに比べるとセキュリティを確保することは根本的に難しくなってしまっている。
オペレーティングシステムベースのProtection ringsや、プロセスべースの孤立化といった機能は、OSレイヤーにおいて、セキュリティを増加するために使われる事ができるかもしれない。
障害分離 (SFI) マシンコードのレベルで、少ないインストラクションセットと、制限されたコマンドセットにコンパイルすることによる方法だ。 許されてない一連の外部のオペレーションを含まない、保証されているバイナリーであるかどうか解析的に調べることによって、 サンドボックスは、ルールを強制することが出来る。
SFIは魅力的なサンドボックス化の手段のひとつだ。何故なら証明手段はただ信頼されている構成要素であり、最小の信頼されているコードを使うだけで実装できる。それによって、信頼出来る小さなコードベースとなり、システムを簡単に検証することが出来るゆえに一層安全となる。
可能性によるセキュリティはプログラムは使われるべきでない機能や資源についての参照を持つことが決して出来るべきではないという設計原理である。 Orwellの1984年の “英語の表現力を制限することによる個人の思考の抹消” による"Newspeak"に似ているものとして、最も単純に分かりやすい。 もし不法な思考を述べるための言葉さえも持たなければ、法を犯すことは出来ないだろう。プログラムにおいての原理も同様だ。
スマートコントラクトのシステムは、特定の言語のみで書かれるようにすることによって、 信頼出来ないコードをサンドボックス化することが出来る。
プログラム言語Eは、騙すことが出来ない可能なトークンを使うことによって、 全てのリソースがアクセスされるようにデザインされた言語である。 Javascriptのような根本的にインタープリター型の言語が根本的に似ている原理を用いている。 その言語は只特定のクラスと機能を持っている、ー例えばブラウザ上で動くwebのAPI-である。 あるシステムはこれらの同じプロパティーを用いて、別々のカスタマイズされた言語を実装することも出来る。 しかし不幸なことに、もし可能性ベースのセキュリティは、使われているサンドボックス化のレイヤーただ1つのレイヤならば 全てのコントラクトの作者は他のコンテキストでは広く使われていない1つの言語を使わなければならなくなってしまう。
Google’s Native Client は大半のコンピュータのプロセッサーによって用いられている低レベルのコマンドである、信頼出来ないx86コードを実行するためのサンドボックスである。 ネイティブのクライアントは、ウェブサイトが通常HTML/CSS/Javascriptに制限されていることに反して、 コンパイルされたバイナリのコードをウェブ上で走らせるために開発されている。 ネイティブのクライアントは、潜在的に悪意あるコードからユーザーを守るために、 制限されたソフトウェアの障害分離の上に数々の改善を行っている。
ネイティブのクライアントはあらゆるプログラミング言語を走らせるために使われる事ができ、 現在はC, C++, Python,V8 Javascript, Ruby, Go, Mono, Lua そして最新のNaClのX86-32とx86-64の構造もサポートしている。 同様にARM、MIPSもサポートしている Goolge はネイティブクライアントを、多大なコンピューターパワーを必要とするウェブアプリに使用している、例えばHangouts Video や QuickOfficeでありこれらの中で、chrome OSのアプリと信頼出来ないコードのホスティングを行うデータセンターにも使用している。 最新のベンチマークでは、 benchmarks 最新のものは運べるネイティブのクライアントのモジュールを店、10~25% LLVMでコンパイルされたネイティブのコードよりも遅くなっていることを示している、それゆえに、ネイティブクライアントは立ちあげの際に効率的なだけでなく、高性能な実行をもっている。
Codiusはネイティブクライアントを用いている何故ならば、セキュリティ、パフォーマンス、柔軟性の独自のコンビネーションを提供しているためだ。 ネイティブクライアントはVMよりもかなり軽く、コンテナを扱うOS全体の表面よりも小さな攻撃面となっている。 仮想マシンとコンテナは将来的にパフォーマンスとセキュリティのより良いバランスになるように開発されていくかもしれないが、 現在のところは我々の要求を満たしていない。
コントラクトが特定の機能ベースのプログラミング言語によって書かれているように求めることは、 システムに採用されることを不必要に遅らせることになるだろうと議論した。 むしろ、ホストのいくつかの著者が、カスタムか、資格準拠の言語によってコントラクトが書かれることを好むのであれば、 彼らはネイティブクライアントのサンドボックスの中でも書くことが出来るだろう、そして他のセキュリティレイヤーを与えることが出来るだろう。 全てのプログラミングをサポートするために十分に柔軟である一方で、 ソフトウェアの障害分離とネイティブクライアントは小数の信頼できるコードには依拠しており、 そして既に開発されて広く使われていrうモジュールの再利用を認めている。
喩えスマートコントラクトのコードがサンドボックス化され、そして機能が制限されてもスマートオラクルは 特定のAPIを、スマートオラクルが走らせるコントラクトに対して用いることを望むだろう。 機能的により粒度の大きなコントロールをコントラクトに与えるために、 Codiusのコントラクトの執筆者は、どのAPIに対してアクセススべきなのかを明白に定義する。
コントラクトのホストが彼らが選んだAPIを開発し、提供する事が出来るとしても、 我々はサンドボックス内での外部のAPIを用いたコードの実行に対して全体的に議論する。 APIは、複雑な機能を提供するためのブロックであるが、スマートオラクルはの信頼出来るコードの一部でならなければならない。 モジュールは、一方で開発され、コントラクトに組み込まれる事が簡単に出来るが、ホストに組み込まれるものではない。
Although contract hosts can develop and expose any APIs they choose, we would in general argue for an approach that emphasizes code inside the sandbox over external APIs. APIs are the building blocks for complex functionality, but they must become part of the trusted code base of the smart oracle. Modules, on the other hand, can be easily developed and included for specific contracts and are not integrated into host.
Below we describe some of the core APIs we expect smart oracles to offer, and those that Codius will provide.
下記がスマートオラクルが提供すると想定している核となるいくつかのAPIである。 これらはコーディウスによって提供されるだろう
コントラクトの鍵となるプロパティの一つに暗号的なIDを持っていることがある。 とりわけ、走っているコントラクトのインスタンスは、 コントラクトの当事者に対して、コントラクトのホスト上で特定の同定されたコードベースを実行していることを証明しなければならない。
以前のセクションでは、どのようにして契約当事者がコードのハッシュに対して同意するのかを述べた。 特定のホストにおいて走っている特定のインスタンスのハッシュと結びつけるために、ホストはユニークなコントラクトとその公開鍵のキーペアを生成するだろう。
多くのコントラクトの使われ方は暗号を求めている。原始的な暗号はサンドボックス内で実装される一方で、多くの暗号的なプロトコルは 乱雑さを生成するためのよい源、ランダムな値を求めている。 それ故にスマートオラクルは乱雑さを手に入れるためのAPIを提供し、ホストが十分に安全だと考える暗号アプリケーションを提供できるようにするべきだ。
古典的なオラクルの目的は情報交換の現実世界と、スマートコントラクトの状態に対しての情報を提供するためだ。 一般的にはこれはインターネットを通じたサービスによって提供される。 たとえHTTPサービスがはるかに面白くないものであるとしても、（OSI Layer 4, 例えばTCP/UDPのように） APIの可能性を制限する理由がない。 このことは全てのアプリケーションのプロトコル、例えばHTTP,SMTPそしてbitcoin,Rippleでさえもた外部に向けて直接トランスポートレイヤーを作ってやるだけで、サンドボックス内から呼び出せすことが出来るということだ。
CodiusはTCPとUDPのためのAPIを提供している。現在は、外部に向けたソケットのみを提供している。 なぜなら我々はコントラクトが短い間だけ実行されるプログラムであるだろうと捉えているためからだ。 しかしながら今後、リッスンとハンドリングのイベントのための機能も同様に開発されるかもしれない （コントラクトがリクエストが来るまで保留されてもよいようにする機能等）
コントラクトが一層複雑になるにつれて、その複雑さを管理しなければならなくなるだろう。 このとき個々のコントラクトをコンパイルして1津のバイナリーかソースコードのファイルとすることが可能かもしれない。 しかしながら、コントラクトがアクセス可能な仮想的なファイルシステムを実装することは一層うなずけることだ。 Codiusのコントラクトでは、スマートオラクルがアクセスコントロールを強制出来るように、 コントラクトがリンクしたあらゆる静的なファイルのハッシュを含めなければならない。
正確な実装は似ているかもしれないが、ファイルシステムのAPIでは、 モジュールを含む機能とは少しことなっている。 モジュールを含むことは他が書き、完全なものとなったコードとの重複をコントラクトが避けるために役立つ。 仮想ファイルシステムを持つことに依って、コントラクトの記載社は論理的にプロジェクトを構造化することが出来る。 更に言えば多くの普通のコードのプロジェクトやユーティリティが、 ファイルシステムのコマンドを使って書かれ、そしてファイルシステムの構造を真似ることで、既存の問題をサンドボックスに追いやることを劇的に簡単にする。
我々はコントラクトがローカルのストレージの有用性を利用することを望むだろうと想定している。 ファイルシステムに書き込み権限を与えることは賢くないように見えるが、ウェブブラウザのローカルストレージと同等のものとして有用なものであると証明されるだろう。
正確な時間の情報に対するアクセスが出来ることはあらゆるコンピューティングを行うプラットフォームにとって有用である。 例えば、いくつかの暗号アルゴリズムでは、例えば時間制ワンタイムパスワード (TOTP), では正確な時間への参照を必要とする。
分散形データベースをより効率的に公平に正確にするために、高度に正確な時計は分散形のデータベースにて用いられている、例えば、Google’s Spannerである。 Google はGPSと原子時計と作動している、何故ならこれらのデバイスは安く購入出来、 とても正確な、とりわけ一緒に使う際により正確なタイミングのデータを提供しながら作用するためだ。 コントラクトのホストは、呼び出すことが出来る最も正確な時計を使うことを推奨する。
我々が上記のようにAPIが大半のスマートオラクルによって、利用可能になることを望むとしても、 包括的な可能性を全て上げたわけではない。スマートオラクルは一連のAPIを定義し、カスタムのAPIの開発を提案し、開発することさえ行うだろう。 しかしながら、先に述べたように、モジュールはより複雑な機能を装備するための主要な仕組みであるべき一方で、 APIは建設するためのブロックであると考えられるべきだと、我々は主張する。
BitcoinやRipple によってこのシステムが触発されたものであったとしても、 スマートオラクルシステムは特定の分散形のネットワークから独立しており、 そして上記のようなネットワークとやり取りすること制限すらされないことを 我々はこの事実を強調しなければならない。
最も基本的なスマートオラクルの実装においては、1つのオラクルだけを含む オラクルはコードを適切に実行すると信頼されており、参加者は誠実に スマートオラクルが何かのアセットや、契約の支配権と共に消失してしまわないだろうことや、契約当事者との腐敗に手を染めないことを信頼出来なければならない。
現在の多くの会社は、プログラミングコードを他のビジネスや、個人のためには走らせる、もしくは走らせるであろうと信頼されている。 1つの信頼されているホストのモデルは、インターネットやソフトウェのホスティングサービス、そしてSaaSのプロバイダーの仕組みとよく似ている。 我々は多くの使い方において、1つのホストを使うことによるセキュリティが十分であるだろうことを予想し、 そしてそのような設定がシンプルであることが、より一層魅力的な選択肢となると考えている。
スマートコントラクトが、検証な形でアウトプットを公開するためには、 スマートオラクルはそれぞれのコントラクトを、固有の公開鍵と秘密鍵の組とともに提供することになるだろう。 オラクルは暗号的にそれぞれのスマートコントラクトに対しての公開鍵と秘密鍵のペアーを生成したことを宣言することが出来る。 スマートオラクルは、最もよく知られた簡単にアクセスできる公開鍵のペアとなり、契約当事者は彼らからの署名を検証をすることが出来る。
1つのホストのモデルでは、秘密の値を共有することが出来る、例えば 例えば、中央集権的なウェブサービスでいうところのに対してのAPIの鍵などだ。
このようにして、暗号的な署名を使う代わりに、APIの鍵を使って 契約の結果もしくは、ある種のトランザクションを開始したことや、そのトランザクションの結果を知らせる事が出来る。
喩え1つのホストのモデルが数多くの使い方やシナリオに十分であると考えられるかもしれないが、 高額、もしくは信用度の低いシナリオである場合には、多数のホストのモデルに依ってスマートコントラクトのシステムは提供されるのが一番良いだろう。 このモデルでは、コントラクトコードは幾つかの独立したスマートオラクルに分散される。例えば10個とする。
そして契約の結果が実現するために、多数のオラクルがその結果に合意しなければならず、幾つの合意が必要かがしきい値として設定される。 これは1つのホストだけのモデルよりも設定に費用が掛かるが、 潜在的な単一障害点が無くなるために、より良いセキュリティを保障することが出来るだろう。 例えば、１０個のうち７個の署名が必要とすれば、３つのオラクル迄は、悪意を持っていたり、オフラインであったりもしくはハッキングされていても、システムは正しく動く。しかしそれはより良いセキュリティの保証を与えるなぜならば単一障害点がないからだ。 実際には、複数のホストのモデルは暗号学的なマルチシグネチャーや、しきい値暗号の仕組みを使って実装されるだろう。両者を下記に記す。
マルチシグの仕組みは、多数の予め決められたエンティティが1つの情報に対して署名を行うことで、 特定の数の固有のエンティティの署名が存在しているのであれば、結果は有効であると考えられる。 そして、それぞれのインスタンスは固有の公開鍵と秘密鍵の組みを与えられ、 1つのホストのモデルと似ていて、それぞれのスマートオラクルは公開的にキーペアが、 システムの中で走ってるコントラクトに対して固有であることを公衆に対して証言するだろう。 コントラクトのインスタンスは互いに署名を中央のエンティティに送るか、もしくはどこかに公に公開する。
現在はビットコインのスクリプトはアカウントの管理下にあるマルチシグを可能としており、 Rippleでは、現在マルチシグを対応中である。 BitcoinかRippleのアカウントが幾つかのスマートオラクルの上で走っているコントラクトの鍵のペアによって コントロールされるようにせて値されることが出来るのであれば、共に存在するって コントラクトは排他的なコントラクトを他のアセットに対して持つことになるだろう。
現在のところビットコインのスクリプトはアカウントの管理下にある複数の署名を可能としていて、 Ripple のまるち
マルチシグの欠点は、署名が有効であることを証明するのは、 ビットコインと、Rippleのトランザクションの証明者にとって比較的に費用がかかるオペレーションであることだ。 それゆえ、一層の署名を1つのトランザクションに加える事は、 高価なトランザクションの費用を必要とすることとなるだろう。 それにもかかわらず存在するこのモデルの利点は、全てのコントラクトが互いの結果と関係が無い結果をアウトプット出来, 例えば契約の資本について絶対的な支配権を持っている契約当事者のような、他のエンティティによって 自明に集めることが出来ることだ。
不幸なことに、このスキームに参加する大半のホストは、 一層の署名が送られなければならない。 この問題はとりわけ、全ての証明者が全ての署名を承認しなければならない分散形のコンセンサスネットワークに対して生じる。 このため、大半のコンセンサスネットワークは、署名の数と、署名者の数に上限を設けている。 例えば、これを書いている間、ビットコインでは、15人の署名者迄の許可を通常のトランザクションに設けている。 この問題をいえば、しきい値をもつ署名のスキームは、魅力的な選択肢となる。 何故ならば、どれだけ多くの当事者が署名に参加したとしても、これらの結果はただひとつの有効な署名となるためだ。 次のセクションにてしきい値をもつ署名のスキームについて議論する。
しきい値をもつ署名は数学的に多数の異なる署名を組み合わせて計算される署名である。 異なるしきい値署名のスキームは、使用される正確なしきい値に対して異なる数を許容しているため、恣意的なしきい値も支持してしまうことにもなっている。 組み合わされた秘密鍵はことは決して復元されることなく、 むしろ独立した断片として別々に計算して導き出された署名の断片を統合して１つのデータとするものである。
楕円曲線暗号のアルゴリズムのしきい値は、 Ibrahim, M.H. et al (2003) と Goldfeder, et al (2014) によって示された方法である。 他の間にあるBitcoinとRippleが使われているタイプである。 そのアルゴリズムによって、どの当事者も互いの秘密の値を知ることは出来ない。 (A+B) G = AG + BG 署名は不可分なものとして通常の楕円曲線暗号の署名から生成され、 BitcoinやRippleと共にすぐに動くようになる。このことは恣意的なしきい値のスキームは不可能にしている。 更に言えばこのアルゴリズムによって、多数の当事者の計算をもちい、 署名を生成するためにはコントラクトのインスタンス同士が互いに通信し、お互いを知らなければならないことを示している。
Schnorr の署名アルゴリズムは、複数の独立した署名の組み合わせがが1つの生成された署名となることを可能とするスキームの例である それぞれの署名エンティティ、スマートオラクルの1津の上で稼働しているコントラクトのインスタンスは署名を生成して、発行する事が出来るだろう。ほかのエンティティは署名の共有しているお互いの証明を行うことが出来るだろう、そしてもし十分な数があり、組み合わせる事が出来るならば。 OpenSSH は最近Ed25519として、Ed25519Schnorr signature を追加した。, そしてrippleも最近サポートした。 Ripple Schnorr 署名 のアルゴリズムの1つの例としては、複数の独立した姿勢された署名を1つの署名にするものがある。 それぞれの署名エンティティ、スマートオラクルの1つの上で走るコントラクトは 他のエンティティは署名の共有の各々を認証する事が出来る。そして十分な数が揃えば結合する。
不幸なことにBitcoinではEd25519に対応していない、それゆえ特定のしきい値のスキームは現在のところ適合しない。 それにもかかわらず、Ed25519は構成可能で柔軟なしきい値署名を作るために効率的なアルゴリズムであり、それゆえ 我々はSchnorr 署名が複数のホストによるスマートオラクルのモデルに、適合する良い仕組みではないかと考えている。
もっとも柔軟なスマートオラクルの一つは、契約当事者が、コントラクトの実行の対価としてスマートオラクルに支払う請求システムである。 その請求システムは、完全にコアとは切り離されたものであり、それゆえにスマートオラクルは、 クレジットカードからビットコイン迄どのような支払いの方法を契約当事者が選んだとしても受け付ける事が出来る。 費用がプリペイド式なのか、コントラクトの実行後請求されるのかについては、スマートオラクルのオペレーターが決めることが出来る。
スマートコントラクトが提供しようとする幾つかの保証が下記にある。
- 正当性 - コードは誠実に書かれたまま実行される
- 可用性 - いつでもそのコントラクトとやり取りを行うことが出来る
- 秘匿性 - 明白に公開されようとしている値ではないかぎり、公開されない。 スマートオラクルに対しての我々の提案は、フォールトレランス性のための特定のアルゴリズムを強制しないことだ。 それはフォールトレランス性の水準は完全にコントラクトに依存することを意味している。
我々の解析では、しきい値アルゴリズムを用いているコントラクトの例では、 t が しきい値(threshold)そしてnがコントラクトホストの合計である。 その閾値tは1より大きくなければならず、nよりも小さくならなければならない。 署名を生成するためには、t+1の署名者を必要とする 我々が、幾つかのクライアントによって全てのコントラクトに対してのリクエストが開始される事を想定している。 それぞれのクライアントが自らのリクエストを成功させようとすることを想定している。 そのようなコントラクトは、tの過ち迄は正当性を保証し、 また、(n - t) -1の過ちが起きるまでの、秘匿性の保証に対してのフォールトレランス性を保証する、可用性を提供する
強く秘匿で有ることが求められているのであれば、契約当事者には幾つかの選択肢を持っている。 彼らはコントラクトを幾つかのパーツへと区分し、そしてそれぞれのパーツに対して異なるコントラクトホストの組みを使う方法を選ぶかもしれない。この場合には、異なるコントラクトの組みの間の関係を隠すために、秘匿化された署名を使うことが可能だ。
暗号技術を用いたその他の選択肢には、 コントラクトホストが作動する実際のデータを彼らから隠すための例えば準同型暗号化と、ゼロ知識証明のような技術がある。
最後に多くの場合には当事者は、オフラインのコントラクトを用いるかもしれない。 この場合においては、どのコントラクトホストも争議が起こらない限りは、自身の情報を見せる必要がない。 こちらのセクションを参照 オフラインコントラクト.
スマートコントラクトに対しての参加を管理するために、それぞれの当事者は、 コントラクトホストとのやり取りをクライアント側で実装するためのソフトウェアが必要となる。
多くのコントラクトのモジュールのために、対応するクライアントのソフトウェアがある。 使い方に応じて、これらのソフトウェアは、きれいなGUIから、シンプルなコマンドラインツール迄、使われるだろう。 この白書の目的として、我々はコントラクトの作り手が適切なクライアントも提供するか、 第三者の開発者が既存のクライアントがコントラクトとやり取り出来るようにするための説明を提供するか出来るようにすることを目的としている。
現在の法律のシステムでは大半のコントラクトは完全にオフラインである。例えば、法律を結ぶ度に裁判所に契約書を提出することはない。 法的な機関を呼び出すという脅威があるため、当事者は契約における合意条項を守ろうとするためだ。 スマートコントラクトの領域においても、オフラインのコントラクトは同様に可能性があり有用である。 当事者間では下記のようなプロトコルによって、オフラインコントラクトを結ぶ。
- 合意した契約を破った場合に、互いの当事者に対してペナルティがあるコントラクトを作成する。
- ランダムな値を契約のコードの最後に加える。これはそのコントラクトコードのハッシュ値から、コントラクトの詳細を推測することを困難にするためのものである。
- 公開鍵と、コントラクトが受け取るであろう鍵についての情報を、1つないし複数のホストから受け取るリクエストを送る、 だが決して本物のコントラクトをアップロードしてはならない。
- エスクロー、もしくはその他の形で他の人の手にある資金に対して、１つもしくは複数の公開鍵を渡す
- 互いにオフラインで合意内容を執行する。
- もし契約当事者の相手方に対して契約違反があれば、被害者はコントラクトをアップロードして、 契約不履行に対しての罰則を貸すためのコントラクトを走らせる。
どの契約当事者も不正を働かない限りにおいて、コントラクトは決してアップロードされ、実行されることはない。 下記に注意して欲しい。
-
もし契約当事者が不正を働いた場合には、他の契約当事者は契約を本当にアップロードして、ペナルティを課すことが出来る という恐れに対して信頼しなれければならない。 繰り返すが、契約当事者が契約当事者が訴えるだろうという信頼出来る恐れを持っているという点において、上記のことは現在の法律システムと似ている。 スマートコントラクトにおける1つの違いは、 "適している"ことは幾分安価（無料に近い）であり、早く（即時に近い）、そして予測できる結果を生む。
-
上記で述べたように、このタイプのコントラクトは争議が起きない限りに、コントラクトを走らせるコストをかけないで済む。 これはどのようにしてコントラクトホストが収益を上げるかということに対しての疑問を持ち上げる。
我々は2つの方法を考えている。 1. コントラクトのホストが、争議が起こった際に収益を上げられる。 2. コントラクトのホストは、公開鍵を発行することから収益を上げられる。
- Step3において、コントラクトが実行されてしまうことを避けるためには、IDベースの暗号を用いるか、identity-based cryptographyもしくは同一のホストの全てのコントラクトは同一のキーで署名することが出来るようにすることで、避けることが出来るだろう。（だがある種のメッセージに対しての制約、例えばメッセージが コントラクトのハッシュ値を含む特定のフォーマットであることを強いること、が必要だ） そのような機能を提供するかどうかの選択をするのはコントラクトホストである。
スマートコントラクトは、明確なコンディションとアウトプットを構成しているあらゆる種類の合意と関係性を形成するために使われる事が出来る。スマートオラクルはその実装を簡単で柔軟で、パワフルなものとする。
私達が想像するそのようなアプリケーションは下記のようなものだ。簡単なものから、複雑なものへと列挙している。 システムが大変拡張可能なものであれば、エコシステム更に広がり、 コントラクトのホストが今まで出来上がってきたモジュールや、既存のコントラクトを用いて機能提供が出来る事を期待出来る。
-
価値のネットワークの橋となること。 BitcoinやRippleのような分散形のネットワークは、それぞれ別々の台帳や、アカウントと残高の追跡を行っているブロックチェーンを維持している 伝統的な金融システムは同様にして自身の台帳を所持してきた。 スマートオラクルの上に出来上がるコントラクトは、自動的で完全に信頼できる分散形のシステム間の橋となるだろう。 そのような橋が1つのシステムの支払いを受け付け、すぐさま他のアカウントでの通貨を発行したり、他の支払いを開始したりすることが出来る。
-
エスクロー スマートコントラクトによって、2人の人間の間の交換を監視するためのEscrow用のアカウントを簡単に作ることが出来る。 商品や所有権やサービスの購入者が支払いをコントラクトのアカウントに届けるだろう。 そのコントラクトは外部のシステムを監視する、例えばドメインの名前のためにあるWHOISのレジストラや、不動産の所有権台帳だ。 所有権が販売者から購入者へと移されることをコントラクトが確認できると同時に、自動的に保持していたファンドを売り手に解放する。
-
暗号通貨の財布のコントロール 現在のビットコインやRippleは、売り手が買い手に変わって支払いトランザクションを開始し、 クレジットカードとデビットカードが行うやり方で、プル型の支払いを行うための良いメカニズムを持っていない。
コントラクトによってコントロールされているウォレットが増えることによってに、様々なタイプの複雑な所有権を内包することが出来るようになる。 毎日の定期引き出しシステムから、特定のエンティティに対してのアクセスを許したり、拒絶したりするシステム迄だ。 これにより定期購読や、条件付き支払い、そして粒度の大きいウォレットに対してのアクセスを秘密鍵を開示することが可能となる。
-
デジタルアセットのオークション もしデジタルアセットや、タイトルに対して所有権がスマートコントラクトに対して与えられているならば、 スマートコントラクトはオークションに対してのルールを自明に実行する事が出来る。 指値の際には、BitcoinやRippleのようなネットワーク上でのシステムにおいての支払いを受け付け、 そしてオークションの勝者以外には全て支払いを返すシステムを設定する、 もしくは、オークションの勝者によってのみコントラクトへコードをサブミット出来るような仕組みを作る事ができる。
-
デリバティブ デジタル、ないし非デジタルのアセットのパフォーマンスを監視するためのコントラクトが、先物取り引きや、先渡取引、スワップ取引や、オプション取引の中で使うことが出来るだろう
-
負債とエクイティ 事前に定義されたルールに従って実行される支払いと権利に基づくその他の証券取引においては、 スマートコントラクトとして書くことが出来る者が含まれる。
-
スマートプロパティ 古典的なスマートプロパティの例は、誰が所有者か分かる車だ。移転可能であるが、偽造することが不可能なディジタルトークンである。 コントラクトは所有権の移転とそれに伴う条項を管理するために設定される。 このことは一時的な権利の移譲を行い、潜在的に負債として所有権を使うような他の合意をも含む。
-
選挙 将来スマートコントラクトは、民主的で官僚的で、その他の形の支配の構造を資産や、組織にさえ及ぼすことが出来るようになるだろう。 他のすべてのアプリケーションとともに、コントラクトは事前に定められた契約を執行し、自らの契約を変更するためのルールすら含んでいる。 多くの非金融的なアプリケーションは、より一層複雑な基盤をもとめ、一層開発されたエコシステムを必要とする。 それ故に、選挙システムが出来上がる迄には時間がかかると考えている。
スマートコントラクトは、技術、ビジネス、法律の新しいフロンティアだ。 この文書と我々の実装に依って、スマートコントラクトの概念が現実となることに寄与できることを望む。
スマートオラクルは、現実世界の情報を提供するオラクルの概念と、コードが実行されるサンドボックス環境の概念を結びつけたものだ。 それは既存の分散形のビットコインやRippleのようなシステムとは独立しており、あらゆるインターネットベースのサービスと交流することが出来る。このことは分散形の合意形成データベースをも含む。 信頼出来ないコードを分散形のネットワークから切り分け、複雑さを減らす、そして、そのようにしてどちらのシステムにおいても、セキュリティを向上させることが出来る。
Codiusの実装では、信頼出来ないコードをサンドボックス化するために、Google のネイティブクライアントを用いており、 このことは開発者があらゆるプログラミング言語でコントラクトを書くことを可能とする。 決定論的なコンパイル、ハッシュ、コントラクトとモジュールのIDを安全に証明されるための署名されたキー、を使っている。
我々は、信用の必要性を減らし、高い価値をもたらす使い方のための分散形のコンピューティングに対しての多数で行う署名の方法を提案する。
Codius とスマートオラクルは、開発者と起業家と、企業向けの法律と金融の専門家にとって全般的に新しい可能性を開いている。 長い法的な条項が必要とされる合意を、コードに翻訳して、自動的にスマートオラクルで実行することが出来る。 スマートコントラクトは、人々が公正でより良く、柔軟な法的なシステムを可能にする力を秘めており、 スマートオラクルは、それらを実現する最もシンプルなシステムの一つである。
参加したいと思いましたか？もしそうなら私達のコミュニティへ是非! www.codius.org
この文書は、サンフランシスコのRipple Labに在籍するEvan SchwartzとStefan Thomasによって執筆されました。 オフラインコントラクトを指摘してくれたDavid Schwartzに感謝します。
お世話になったコミュニティは多すぎて書ききれません。 けれども、幾人かのとても貢献してくれた個人とチームに対してここに謝辞を述べたいと思います。
-
Gavin Andresen programmable oraclesoraclesのアイディアについて
-
Mike Hearn フィードバックと、ひらめき、初めての smart contracts に対しての仕事、 そしてスマートコントラクトを現実のものとするための絶え間ない努力に対して。
-
Social Minds Inc. (Reality Keys), Orisi チームと [Early Temple project]を現実に実装したことについて(http://earlytemple.com/) - solo and multi-signature - oracles.
-
Ethereum チーム スマートコントラクトのプラットフォームを与え、 何千人もの新しい人々にコンセプトを広めたことに対して
-
Google とそのNative Client チーム フィードバックと、いつものサポートに対して
-
James Hazard CommonAccord 彼のフィードバックと、その白書について