ボム君.com

うどんの仮想通貨・暗号通貨ひろば

暗号通貨・仮想通貨について色々なことを書いていきます。

Æternityのホワイトペーパー和訳

f:id:udoncryptocurrency:20170630185413p:plain 個人的に、Æternityのホワイトペーパーを和訳しました。私費で翻訳したので、少しでも寄付をいただけましたら幸いです…。なお、あまりチェックできておりませんので、随時直して更新していきたいと思います。 ETH Address :udonpro.eth (0x6De754C0816aa1EC98D2fF55AD6ea7D00ab6E131) なお、GithubWikiでも同じものを載せました。https://github.com/aeternity/wiki/wiki/Whitepaper_Japanese

Æternity blockchain

トラストレスで、分散化された、純粋に機能的なオラクルのマシン。 2017年2月6日 v0.1

  • Zackary Hess zack@aÆternity.com
  • Yanislav Malahov yani@aÆternity.com
  • Jack Pettersson jack@aÆternity.com

概要

2014年のEthereumの導入以来、分散型のトラストレスなアプリケーション(スマート・コントラクト)に大きな関心が集まっている。その結果、多くの人が実世界のデータを持つアプリケーションをブロックチェーンの上に実装しようとしてきた。いくつかの理由から、我々はアプリケーションのステートとコードをチェーン上に格納することは間違っていると考えている。 我々は、スケーラビリティの高いブロックチェーンアーキテクチャを提示するが、それはオラクルをチェックするのにも使用される。これにより、オラクルは非常に効率的になる。なぜなら、1つのコンセンサス・メカニズムを別のものの上に重ねることを避けるからだ。ステート・チャネルは、プライバシーとスケーラビリティを高めるために統合されている。チャネル内のトークンは純粋に機能的なスマートコントラクトを使用して転送されるが、そのコントラクトはオラクルの出したアンサーにアクセスすることが可能だ。コントラクトコードやステート・オンチェインを保存しないことで、事実上の機能性を大幅に損なうことなく、スマートコントラクトの分析や処理の迅速化を実現できる。 合成アセット市場や予測市場などのアプリケーションは、世界規模で効率的に実装できる。Erlangでは、いくつかの部分は概念実証の実装をしている。ウォレット、ネーミング、アイデンティティシステムなどの開発ツールとアプリケーションの基本も提供されるだろう。

内容

I はじめに
I-A これまでの仕事

II Æternity ブロックチェーン
II-A トークン、アカウントおよびブロック
II-A.1 アクセス・トークン, Aeon
II-A.2 アカウント
II-A.3 ネーム・システム
II-A.4 ブロック・コンテンツ
II-B ステート・チャネル
II-B.1 スマート・コントラクト
II-B.2 事例
II-C コンセンサス・メカニズム
II-C.1 オラクル
II-D ガバナンス
II-E スケーラビリティ
II-E.1 シャーディング・ツリー II-E.2 ライト・クライアント II-E.3 ステート・チャネルと並列性/並列処理
II-E.4 所定のメモリ必要量での1秒あたりのトランザクション

III アプリケーション
III-A   ブロックチェーンに不可欠なもの
III-A.1 アイデンティティ
III-A.2 ウォレット
III-A.3 プルーフ・オブ・イグジスタンス(存在証明)
III-B   ステート・チャネル・アプリケーション
III-B.1 トール API III-B.2 保険付きクラウドファンディング
III-B.3 クロスチェイン アトミック・スワップ .
III-B.4    安定した価値資産とポートフォリオの複製 III-B.5 イベント・コントラクト
III-B.6 予測市場
III-B.7 単一の価格でバッチ取引を行う市場

IV 実装
IV-A 仮想マシンとコントラクト言語
IV-B ウェブ統合による導入
IV-C オープンソース・モジュール
IV-D ユーザビリティとUX設計

V 検討
V-A 制限/限界とトレードオフ
V-A.1 オンチェイン・ステート
V-A.2 フリー・オプション問題
V-A.3 流動性の損失およびステート・チャネル・トポロジ
V-B 今後の課題 Future work
V-B.1 機能的なコントラクト言語
V-B.2 マルチ・パーティ・チャネル

I. はじめに

この論文の目的は、Æternityブロックチェーンアーキテクチャと可能なアプリケーションの概要を示すことにある。特にコンセンサスとガバナンスのメカニズムについては、より詳細な論文が今後発表される予定である。しかし、我々のアーキテクチャが全体的であることに留意すべきだ。つまり、すべてのコンポーネントは連携して、モジュール方式で相乗効果を発揮する。 この論文の残りの部分は4つの部分に分かれている。まず第1に、我々のアーキテクチャを伝える基本的な理論を紹介し、議論する。第2に、含まれている必須アプリケーション、その他の可能なユースケースについて議論し、開発者としてこのプラットフォームを使用する方法についての直感的知識を示す。第3に、Erlangで書かれた現在の概念実証の実装を紹介する。そして最後に我々は、起こりうる将来の方向性と他の技術との比較などの検討で結論づける。

A. これまでの仕事

ブロックチェーンのうち、まず最初にBitcoinは、インターネット上の価値交換を設計する新しい方法を示している[1]。 Ethereumは、ブロックチェーンアーキテクチャーで保護されたチューリング完全なスマートコントラクトを作成する方法を示した[2]。 TruthcoinはBlockchains [3]でオラクルを作るツールを作り、GroupGnosisとAugurは効率を上げる方法を示した[4]。 Casey Detrioはブロックチェーンで市場を作る方法を示した[5]。 Namecoinは、ドメインネーム・サーバと同等の分散を実現する方法を示した[6]。 Factomは、ハッシュを格納するブロックチェーンがどのようなデジタルデータのプルーフ・オブ・イグジスタンス(存在証明)として使用できるかを示した[7]。 これらの技術は、最高レベルの財務および法律サービスをあらゆる人に提供するという点で、大きな将来性を示している。しかし、これまでのところ、彼らは一体となってその将来性を実現することに成功していない。具体的には、ガバナンス、スケーラビリティ、スクリプティングの安全性、現実世界のデータへの安価なアクセスなどの点で、これまでのすべてのソリューションは不十分である [need cit.]。Æternityは、これらすべての点で最先端技術を向上させることを目指している。

II. ÆTERNITY ブロックチェーン

我々は、現行の「スマートコントラクトプラットフォーム」にはスケーラビリティ、スクリプティングの安全性、実世界データへの安価なアクセスが欠如していることが、3つの中核的な問題になると考えている。第1に、現状のステートフルな設計はプラットフォーム用に書かれたスマートコントラクトを分析しにくくし(注1)、ステートフル性をシーケンシャルなトランザクション・オーダリングと組み合わせるとスケーラビリティが複雑になる[need cit.]。 第2に、現実世界のデータを分散型で、トラストレスな、信頼できる方法でシステムにするための高いコストは、多くの有望なアプリケーションの実現を複雑にしたり、完全に妨げたりする[need cit.]。 第3に、このプラットフォームは、それ自身を更新する能力に限界があり、新しい技術的または経済的な知識に適応することができない。これら3つの問題のそれぞれには、明確な解決策があると考えられる。

第1に、ステート・チャネル技術に関する最近の研究は、多くのユースケースにおいて、ステート・チャネルを維持する必要はないことを示唆している[need cit.]。 すべての情報をステート・チャネルに保存し、ブロックチェーンを情報交換の経済的結果を解決するためだけに使用すること、および差異 が生じた場合にはフォールバックとして使用することは、ほとんどの場合で可能である。 これは、チューリング完全なスマートコントラクトがステート・チャネルに存在するがオンチェーンでは存在しない、ブロックチェーンアーキテクチャに対する代替アプローチを示唆している。これにより、すべてのトランザクションが独立し、そのゆえパラレルな処理が可能になるので、スケーラビリティが向上する。さらに、これは、コントラクトがシェアード・ステートに書き込まれることはなく、テストと検証が大幅に簡素化されることを意味する。我々は、この設計が、ブロックチェーンはデータストレージというよりは金融ロジックに関するものであることを強調する、と考えている。すなわち、ブロックチェーンを完全に補完する分散型ストレージ・ソリューションが存在するのである。

注1 ステートフルなコントラクトを分析することの難しさは、「The DAO」をもたらした再帰呼び出し脆弱性によって非常にはっきりと示された。複数のEthereumのクリエイターと一般のコミュニティによって監査されたコードであったにもかかわらず、これは起きた[need cit.]。

第2に、Augurのようなアプリケーションは分散的な方法で実世界のデータをブロックチェーンにもたらそうとしたが、それは、内在するブロックチェーンのコンセンサス・メカニズムを利用する代わりに、スマートコントラクトの中でコンセンサス・メカニズムを本質的に構築するプロセスにおいて行われた[8]。 これは非効率になるが、セキュリティは向上しない。これから得られた当然の結論は、次の内部ステートだけでなく外部世界のステートにも情報を提供できるように、ブロックチェーンのコンセンサス・メカニズムを一般化するということだ。 したがって、ブロックチェーンのコンセンサス・メカニズムはどの複雑性理論がオラクル・マシンをダビングするのかという結果を決定する、と主張することができる。つまり、"サッカーの試合Xで勝ったのはどのチームか?"など、必ずしも計算できない質問に対する答えを持っているので、チューリング・マシンよりも強力な理論的マシンであるということである [need cit.]。

第3に、コンセンサス・メカニズムがシステムのパラメータを決定するためにも使用できるということは、自然なことであると思われる。これにより、変化する外部条件に適応することが可能になり、新しい研究や現場での最新の展開を取り入れることが可能になる。このセクションの残りの部分では、アカウント、トークン、名称、ブロックの構造の簡単な概要から始めて、Æternityブロックチェーンについて詳しく紹介する。それに続いて、ステート・チャネルとスマートコントラクトに対する我々のアプローチについての説明、そしてブロックチェーンのコンセンサス・メカニズムを効率的なオラクルメカニズムの作成とシステムの管理の両方に使用する方法についての議論が続く。最後に、さまざまな角度からのスケーラビリティについて説明する。

A. トークン、アカウントおよびブロック

コントラクト開発者の視点で見れば「ステートレス」であるにもかかわらず、Æternityブロックチェーンはいくつかの事前に定義されたステート・コンポーネントを追跡する。我々は、各ブロックの内容と同様に、これらについて説明するつもりだ。話を簡単にするために、このセクションではすべてのノードがブロックチェーン全体を追跡していることを前提とする。可能な最適化については、セクションII-Eで説明する。

A.1) アクセス・トークン, Aeon

ブロックチェーンの使用は無料ではなく、ユーザーはaeonというトークンを使う必要がある。Aeonは、プラットフォームで使用されるすべてのリソースの支払いと、プラットフォームに実装される金融アプリケーションの基礎として使用される。 Genesis Blockにおけるaeonの分布は、Ethereumでホストされたスマートコントラクトによって決定される。さらなるaeonがマイニングされるだろう。 すべてのシステム料金はaeonで支払われ、すべてのスマートコントラクトはaeonで決済される。

A.2) アカウント

各アカウントにはアドレスとaeonの残高があり、トランザクションと最後のアップデートの高さごとに増加するノンスもある。また、各口座は、開かれている時間に対してわずかな料金を支払わなければならない。アカウントを作成して維持するコストは、スパムを防ぎ、ステートの膨張を妨げる。口座を削除する報酬は、スペースの再生の動機付けをする。

A.3) ネーム・システム

多くのブロックチェーン・システムは、ユーザが判読不能なアドレスに苦しんでいる。 Aaron Swartzの仕事とNamecoinの研究によって、Æternityは分散型で安全でありながらヒューマンフレンドリーなネームをサポートしているネームシステムを特徴としている[9]。ブロックチェーンのステートには、独特でヒューマンフレンドリーな記号列から固定サイズのバイトアレイまでのマッピングなどがある。これらの名前は、Æternity上のアカウント・アドレスやハッシュなどを指し示すために使用できる(例えば、マークルツリーのそれ)。

A.4) ブロック・コンテンツ

各ブロックには以下のコンポーネントなどがある。 - 以前のブロックのハッシュ。 - トランザクションのマークルツリー。 - アカウントのマークルツリー。 - ネームのマークルツリー。 - オープンチャネルのマークルツリー。 - それぞれの質問に答えなかったオラクルのマークルツリー。 - オラクルアンサーのマークルツリー。 - マークル証明のマークルツリー。 - 乱数ジェネレータ内の現在のエントロピー。 これまでのブロックのハッシュは、ブロックチェーンのオーダリングを維持するために必要である。トランザクション・ツリーには、現在のブロックに含まれるすべてのトランザクションが含まれている。コンセンサスで作られるツリーを除いて、すべてのツリーは完全に合意に達している。つまり、ツリーがあるブロックから次のブロックに変更された場合、この変更は新しいブロックのトランザクション・ツリー内のトランザクションによるものでなければならず、また、アップデートのマークル証明がブロックの証明ツリーに含まれなければならない。残りの3つのツリーの目的は、以下のセクションで明らかになるであろう。

B. ステート・チャネル

最近、ブロックチェーンの分野で最も興味深いのは、ステート・チャネルの発展である。それらは、ほとんどの場合、トランザクションの影響を受ける人々だけがそれについて知る必要があるという基本原則に基づいて動作する。本質的に、取引当事者たちは、ブロックチェーン上のいくつかのステートを例示する。たとえば、EthereumコントラクトやBitcoin マルチシグなどがある。彼ら(取引当事者たち)は、単に、署名されたアップデートをこのステートに相互に送る。重要な点は、どちらか一方がこれらを使用してブロックチェーンのステートをアップデートできることだが、ほとんどの場合、彼らはそうはしない。これにより、情報が当事者によって送信され処理されるのと同じくらい速く取引を行うことができ、当該トランザクションブロックチェーンのコンセンサス・メカニズムによって検証されるまで(そして潜在的に確定されるまで)待つ必要はない。

Æternityでは、ブロックチェーン上で決済できる唯一のステート・アップデートはaeonの転送だけであり、転送できる唯一のaeonは取引先が既にチャネルに入金しているものだけである。これにより、すべてのチャネルが互いに独立することとなり、チャネルに関連するすべてのトランザクションを並行して処理できるため、トランザクションスループットが大幅に向上するという利点がすぐに得られる。

ブロックチェーンは、最終的な結果を確定するために、または発生する対立を解決するためにのみ使用されるものであり、司法制度に概ね類似している。しかし、ブロックチェーンの動作はあらかじめ分かっているので、ステート・チャネルの意図した結果を論じても得るものはない。つまり、悪意のある者は正しくふるまうように動機付けされ、ブロックチェーン上のファイナル・ステートのみを決済する。これらをまとめると、トランザクションのスピードとボリュームが数桁も増加し、プライバシーも向上するということである。

B.1) スマートコントラクト

チェーン上で決済できる唯一のステートはaeonの転送であるにもかかわらず、Aternityは「スマートコントラクト」を走らせることのできるチューリング完全なバーチャルマシン(VM)をまだ備えている。Æternity上のコントラクトは厳密にはいくつかの規則に従って資金を分配するコントラクトであり、例えばEthereumの実体的なコントラクトとは明らかに対照的である。より際立った実用的な違いが二つある。それは、デフォルトでは、関係する当事者だけが特定のコントラクトを知っているということ、そして、オープンステートのチャネルを持つ当事者のみが有効なコントラクトを作成できるということ、である。当事者がコントラクトに同意する場合は、署名し、将来の参照用にコピーを残しておく。その結果が争われる場合にのみ、ブロックチェーンに送信される。その場合、コードは送信された取引の一部として保存されるだけで、決して他のステートには保存されない。この場合、ブロックチェーンはコントラクトに従ってトークンを分配し、チャネルを閉じる。

 

macro Gold f870e8f615b386aad5b953fe089 ;

Gold oracle

if 0 1000 else 0 0 end

0

例1. 金の価格に対するベットをエンコードする簡単なコントラクト。使用言語はForthのようなChalangであり、セクションIV-Aに示されている。

一例として、 例1は、ある時点で金の価格に対するベットをエンコードする、非常にシンプルなコントラクトを示している。1行目で、マクロGoldは問題のオラクルの識別子を保存する。それは、2016年12月1日に金の価格が$ 38 / g以下であるならば、trueを返す。コントラクトの本文は2\~4行目に表示されている。まず、Gold oracleの識別子をスタックにプッシュし、それをオラクルを使用して呼び出す。これにより、オラクルのアンサーがスタックの最上部に残される。我々が条件分岐を行う場合、これを使用する。つまり、オラクルがtrueを返す場合は、0と1000をスタックにプッシュする。これは、0のaeonはBurnされ、1000のaeonをチャネルの最初の参加者に送らなければならないことを示している。それ以外の場合は、0と0をプッシュするが、2番目の0は他の参加者がチャネル内のすべてのaeonを受信したことを示す。最後に0をプッシュする。これは、このチャネルステートのノンスであると受け止められる。実際の使用では、展開時にノンスが生成される。

注目すべき重要な点の1つは、Æternityのコントラクトがそれ自体のステートを維持していないことである。どのステートも取引当事者によって維持され、実行時にインプットとして送信される。すべてのコントラクトは本質的に純粋な関数であり、いくつかのインプットを受け取り、アウトプット(注2)として新しいチャネルステートを与える。一般的なソフトウェア開発において、特に財務アプリケーションの開発においては、純粋な機能を用いることの利点について数十年に渡って学界や産業界で広く文書に残されてきた[10] [need cit.]。

a) コントラクト・インターアクションとマルチステップ・コントラクト すべてのコントラクトがステートレスであり、相互に独立して実行されているにもかかわらず、コントラクト・インターアクションとステートフルネスは依然としてハッシュロックを介して達成されることが可能である。簡単なハッシュロックを例2に示す。1行目では、スタックがハッシュ hとシークレット sを含むことを期待するハッシュロックという関数を定義した[need cit.]。2行目でそれらを入れ替えるが、それは4行目でhash(v) の等価演算子hを呼び出す前に、3行目のシークレットをハッシュするためである。シークレットがハッシュのプリイメージである場合、これはtrueを返す。この関数を使用して、同じシークレットバリューの存在について異なるコントラクトのコードブランチの実行を述語化することができる。

: hashlock

swap

hash

== ;

例2.シンプルなハッシュロック

macro Commitment a9d7e8023f80ac8928334 ;

Commitment hashlock call

if 0 100 else 0 50 end

1

例3. 仲介人を通じてトークンを送信するためにトラストレスなハッシュロックを使用した。

簡単な使用例として、ステート・チャネルを共有していないユーザーたちは、それぞれの間にチャネルのパスが存在する限り、ハッシュロックを使用すればトラストレスに相互にaeonを送ることができる。たとえば、アリスとボブがチャネルを持ち、ボブとキャロルにチャネルがある場合、アリスとキャロルはボブを介して取引することができる。彼らは、例3に示すコントラクトのコピーを各チャネルごとに1つ、計2つ作成することによってこれを行う。1行目のコミットメントは、アリスが選ぶシークレットのハッシュである。3行目で我々はそれをスタックにプッシュし、ハッシュロック関数を呼び出す。ifのどのブランチが実行されるかは、ハッシュロックの戻り値によって決まる。これらのコントラクトがすべての当事者によって署名されると、アリスはそのシークレットを明らかにし、ボブとキャロルはそれを使って自分たちのaeonを要求することが可能になる。

ハッシュロックは、例えば、 例4に示すように、チャネルでマルチプレーヤー・ゲームをプレーするためにも使われる。各自がゲーム・マネージャでチャネルを作り、すべてのチャネルに同じコントラクトを公開する。たとえば仮に、我々はファンクションのState32と定義されるゲームステート32にいて、すべてのチャネルをState 33にトラストレスに同時にアップデートしたいとする。ゲームマネージャがシークレットを明らかにすると、同時にすべてのチャネルがアップデートされる。

(注2) コントラクトはオークションやいくつかの環境パラメータからアンサーを読むことができるため、完全に純粋な関数ではないことに注意すべきである。しかし、オラクルのアンサーは一度提供されると決して変更されず、不純物というよりはむしろ、オラクルマシンの計算上のリッチさに起因すると主張することができる。 環境パラメータは「必要悪」とみなされ、理想的には高水準言語によって適切に区画化される。

macro Commitment a9d7e8023f80ac8928334 ;

    

Commitment hashlock call

if State33 else State32 end

call

例4. ハッシュロックを使用してマルチプレーヤーゲームを複数のチャネルでプレーする場合を簡略化した例

b) 計測された実行 コントラクトの実行はEthereumの「ガス」と同様の方法で計測されるが、Æternity では計量に2つの異なるリソースを使用している。一つは時間、もう一つはスペースである。これらの両方は、実行を要求する当事者によってaeonを使用するために支払われる。これは望ましくないと考えられる。なぜなら、最初にディスピュートを解決する必要性をブロックチェーンにもたらしているのは、おそらく別の当事者だからである。ただし、チャネル内のすべてのお金がベットに使用されていない限り、これはコントラクト・コードで効果的に無効にすることができる。というのは、それにはある当事者から別の当事者へ資金を再分配する能力があるからだ。実際には、チャネル内の資金のすべてを使って取引をすることを避けることは、一般的には良い習慣である。なぜなら、チャネルを閉鎖するときに、負けた当事者が協力しないようにするからである。

B.2) 事例

これらのアイデアをすべて現実的に考えてみよう。実際に、アリスとボブがÆternity上のステート・チャネルを使用して取引したいならば、次の手順を実行する。 1. アリスとボブは、それぞれがどれくらい多くのお金をチャネルに入金するかを指定するトランザクションに署名し、それをブロックチェーンに公開する。 2. ブロックチェーンがチャネルを開いたら、彼らは新しいチャネルステートを作成し、相互に送信して署名する ことができる。チャネルステートは、チャネル内の資金の新しい分布、もしくは、新しいディストリビューションを決定するコントラクト、のいずれかである。これらのチャネルステートのそれぞれは増加するノンスを有し、両当事者によって署名される。したがって、ディスピュートが発生した場合、最新の有効なステートをブロ ックチェーンに送信することができ、最新のステートを送信することはブロックチェーンを強化する。

  1. チャネルは以下の2つの異なる方法で閉じることができる。
  2. アリスとボブが取引を終えて最終残高に同意すると、それを示すトランザクションに署名し、それをブロックチェーンに送信する。それにより、チャネルが閉じられ、それに応じてチャネルに資金が再配分される。

何らかの理由アリスがでクロージング・トランザクションへの署名を拒否した場合、ボブは両人の署名した最後のステートを送信し、このステートを使ってチャネルを閉鎖するよう要求することができる。これはカウントダウンをスタートさせる。ボブが不正直であるとアリスが考えている場合、彼女はカウントダウンが終了する前に、両人が署名したより高次のノンスを伴ったステートを公表する機会を得 る。彼女がそれを行うと、チャネルは直ちに閉じる。それ以外の場合は、チャネルはカウントダウンが終了すると閉じられる。

C. コンセンサス・メカニズム

Æternityは、プルーフ・オブ・ワーク(PoW)とプルーフ・オブ・ステーク(PoS)のハイブリッドのコンセンサス・メカニズムを使用する。ブロックの生成は、プルーフ・オブ・ワークで決定される。特定のシステム変数は、オンチェーン予測市場システムを介して決定され、それによりユーザーは参加して知識の中に取り入れることができる。PoWアルゴリズムに関しては、我々は現在のところTrompのCuckoo Cycleの亜種を選好している。それはメモリバウンドや「間接的に有用なプルーフ・オブ・ワーク」もあり、実行するために必要な電気が少ないのだが、その代わりに別の制限要因(メモリレイテンシの可用性の一種)がある。これにより、スマートフォンでマイニングすることも可能になる。Trompは彼の仕事について次のように書いている。 「[Cuckoo Cycle]は、即座に検証可能なメモリバウンドPoWであり、コンピューティングではなくレイテンシが支配的だ。その意味で、Cuckoo Cycleのマイニングは、ASICマイニングの一形態である。そこではDRAMチップが何十億ビットをランダムに読み書きするアプリケーションの役割をする。夜間に充電している電話機でさえも、効率を大幅に低下させることなくマイニングすることができる。収益性を重視するのではなく、宝くじを楽しむつもりになれば、マイニングをするハードウェアの先には広大な広がりが見られ、選定や分散の役に立つ」。

プレビュー:コンセンサス・メカニズムは、 Æternityにおいていくらか非標準的な役割を担っている。ブロックチェーンの新しいブロックに同意することに加えて、オラクルの質問に対するアンサーとシステムのパラメータの値の両方にも同意する。特に、コンセンサス・メカニズムは変化する可能性がある。しかし、これは全く難しくないことである点に留意すべきだ。たとえば、単純なプルーフ・オブ・ワークのメカニズムを利用すれば、マイニングをする人たちを買収してオラクルを堕落させるの簡単だろう。したがって、Æternityは、PoSとPoWの新しいハイブリッド・アルゴリズムを使い両方の利点を活用するつもりだ。これとは別に、新しいaeonトークンの発行にはPoWが使われるだろう。

余白注記:元来、Æternityは100%PoSのブロックチェーンであることを意図した。我々は、分散型の100% PoSシステムが可能であるとは考えていない。

C.1) オラクル

ほとんどのコントラクトにとって重要な機能は、テキストとしてエンコードされているのか、それともコードとしてなのか、にかかわらず、異なる商品の価格や特定の出来事が発生したかどうかなど、周辺環境から値を照会する能力である。この能力を持たないスマートコントラクト・システムは、実質的に閉鎖されたシステムであり、明らかにとても有用ではない。これは一般的に受け入れられている事実であり、分散型の方法で外部データをブロックチェーンに取り込もうとするプロジェクトがすでにいくつか存在している[8]。しかしながら、供給された事実が真実であるか否かを判断するためには、コンセンサス・メカニズムの上に新しいコンセンサス・メカニズムを実装することが実質的に必要である。 互いの上で2つのコンセンサス・メカニズムを実行することは、両方を別々に実行するのと同じくらい高くつく。さらに、最も安全性の低いものが攻撃されて「false」の値を生成する可能性があるので、セキュリティを向上させることはない。したがって我々は、2つのコンセンサス・メカニズムを1つにまとめることを提案する。これは、システムのステートに同意するために使い、また、外界のステートに同意するためにも使うメカニズムを実質的に再利用する。 これが機能する方法は次のとおりである。任意のaeon保有者は、イエス/ノーで答える質問に答えることを約束することによってオラクルを起動することができる。その際には、質問に答えるタイムフレームも指定する必要がある。いますぐでも良いし、将来のある時点に始めてもよい。オラクルを起動するユーザーはタイムフレームの長さに比例してaeonを入金するよう求められる。その金はユーザーが真実として受け入れるという回答をした場合には返金されるが、そうでない場合はBurnされる。ブロックチェーンはオラクルのユニークIDを生成するが、それが利用可能になるとアンサーを検索するために使用することができる。

ひとたび質問が答えられるようになると、オラクルを起動したユーザーは無料でアンサーを提供することができる。オラクル・ランチャがアンサーを提供した後、または一定の時間が経過するまで、他のユーザは同じ量のaeonをデポジットすることによって、カウンター・クレームを提示することができる。そのタイムフレームが終了するまでにカウンター・クレームが提示されなかった場合、オラクルを起動したユーザーが供給したアンサーは真実として受け入れられ、デポジットが返却される。カウンター・クレームが提示された場合には、ブロックのコンセンサス・メカニズムがオラクルに答えるために使用される。これはより高価だが、2つのセーフティ・デポジットのうちの少なくとも1つを取ることができるとわかっているので、それを使用することができる。

D. ガバナンス

ブロックチェーンのシステムのガバナンスは、過去においては大きな問題であった。システムのアップグレードを行わなければならない場合は、いつもハードフォークが必要であり、通常は、すべてのバリュー・ホルダーの間で大きな議論が起こる。Bitcoinのブロックサイズの議論で見てきたように、ソースコード内で任意に設定された変数を修正するなどの簡単なことさえも、ユーザーのインセンティブが意思決定者と合致していないシステムや明確なアップグレード・パスがないシステムでは非常に難しいようである。我々はもっと複雑なガバナンスの決定も見てきた。たとえば、「The DAO」の中にあった、たったひとつのスマート・コントラクトのバグを修正したときなどは、システム開発者による迅速な介入が必要になった。

これらのシステムの主な問題は容易に識別できる。というのも、プロトコルのアップグレードや変更の意思決定プロセスが明確ではなく、透明性が欠けているのだ。Æternityの統治システムはコンセンサスの一部である。それは予測市場を使用して、可能な限り効率的かつ透明性をもって機能する。

さらに、コンセンサス・メカニズムは多くの変数によって定義されているが、その変数はシステムがどのように機能するかを決定し、新しいブロックごとに若干アップデートされる。それは、トランザクションを実行したりオラクルに頼むのにかかる費用の額から、ブロックタイムのような基本的なパラメータ値の修正まで(アップデートされる)。

プロトコルを定義する変数に関する予測市場を持つことで、ユーザたちはプロトコルを効率的に改善する方法を学ぶことができる。潜在的なハードフォークに関する予測市場を持つことで、我々はコミュニティがどのコードのバージョンを使用すべきかという総意をまとめる手助けができる。各ユーザーはどのメトリックを最適化したいのか自分で選択するが、単純なデフォルト戦略は自分の保有しているものの価値を最大化することである。

E. スケーラビリティ

E.1) シャーディング・ツリー

これまでに提示されてきたアーキテクチャーは非常に拡張性がある。それは、各ユーザーが自分が気にしているブロックチェーン・ステートの部分だけを追跡し、他人のデータは無視している場合でも、ブロックチェーンを実行することが可能である。新規ユーザーが気にしているサブステートについて確かめるためには、少なくとも1つのステートのコピーが必要だが、各ノードの負荷が任意に小さくなるように、任意の数のノードにわたってこのデータをshard{断片化する}ことができる。サブステートがそのステートの一部であることを証明するために、マークルツリーが使用される[11]。特定のノードがツリーを追跡することに特化するシナリオや、insert関数やlookup関数のための支払いを受けるシナリオを想像するのは容易なことである。

E.2) ライトクライアント

ライトクライアントはブロック全体をダウンロードしない。 最初に、ユーザは自分が好むフォークの履歴にあるハッシュをクライアントに与える。これは、ウイーク・サブジェクティビティと呼ばれる技法である[12]。 そこで、クライアントは、そのハッシュを持つブロックを含むフォークのみをダウンロードする。 クライアントはブロックのヘッダーのみをダウンロードする。 ヘッダーは全ブロックよりもはるかに小さく、処理されるトランザクションはごくわずかである。 話を簡単にするために、我々はセクションII-A.4のブロック構造について説明するときにブロックヘッダーについては言及しなかったが、それには以下の内容が含まれている。 - 以前のブロックのハッシュ。 - すべてのステート・ツリーのルート・ハッシュ。

E.3) ステート・チャネルと並列性/並列処理

スタート・チャネルには膨大なスループットがあるが、それらの内部のほとんどのトランザクションは決して実行されないか、またはブロックチェーンに記録すらされない。 さらに、チャネルはチェーン上のシェアード・ステートには書き込まないので、実際にブロックチェーンに記録されるすべてのトランザクションを並行して処理することができる。今日販売されているほとんどの家庭用ハードウェアには、少なくとも4つの処理コアがあり、トランザクションスループットに約4倍を乗じるという即時効果がある。

さらに、複雑なコンカレント・インターアクションが決して存在しないという事実は、このブロックチェーンアーキテクチャをシャーディングすることは比較的容易であるはずだということを示唆している。ブロックチェーンのシャーディングはまだかなり実験的なので、我々はÆternityの初期設計でシャージング技術を追求しないことを意図的に選択した。しかし、将来これが変われば、Æternityは最も簡単にシャードできるブロックチェーンの1つになるはずだ。

E.4) 所定のメモリ必要量での1秒あたりのトランザクション

プロトコルを定義する変数はすべてコンセンサスによって常に更新されている。 それらの初期デフォルト値から、1秒あたりのトランザクションの初期デフォルト・レートを計算することができる。 ノードを操作するには、ファイナリティのときからすべてのブロックのコピーを保持する必要がある。攻撃がある場合に備えて、さらに100倍の情報を記録できる必要がある。ファイナリティが2日であると推定すると、ファイナリティまでに5760ブロックが存在することになる。 したがって、メモリ必要量は5760 * 1メガバイト* 100 = 576000メガバイト = 576ギガバイトである。 攻撃が起きていない場合には、ブロックを格納するには約5.76ギガバイトしか必要としない。

Note that this is a draft and will likely

change.

We define the following variables for the following calculations:

B = block\_size in bytes

F = blocks\_till\_finality

R = time\_till\_finality in seconds

T = transaction size in bytes

transactions per second = B * F / (T * R)

B = 1000000 bytes = 1 megabyte per block

F = 24*60*2 blocks per day

R/F=30secondsperblock

R = 24*3600 seconds per day

T = 1000 bytes per transaction

1000000 * 24*60*2 / 1000 / 24*3600

= 1000000 / 1000 / 30

= ca. 32 transactions per second (fast enough to sign up every human within 8 years)

III. アプリケーション

Æternityスマート・コントラクトのステートレスな性質により、Æternityのブロックチェーンで以下のアプリケーションを簡単に構築できる。ボリュームの大きなアプリケーションに特に適している。

A. ブロックチェーンに不可欠なもの

ブロックチェーンに不可欠なものとは、aeon、ウォレット、名前、関連概念などの必要な基本要素である。これらは、再利用可能なコンポーネントをモジュール化するが、それらはアプリケーション基盤として使用でき改善することができる。

A.1) ID

各口座には一意のID番号が関連付けられる。 ユーザーは一意の名前とリンク名をデータ構造のマークル・ルートに登録することができる。 データ構造には、自分の一意のIDだけでなく、自分のアカウントに関する他の情報も含めることができる。 我々は、Schema.orgJSONフォーマットを使用して、人や企業のようなものを表現することを目指している[13]。

A.2) ウォレット

ウォレットはソフトウェアの一つであり、Æternityと情報を交信するために使用される。 ウォレットは、aeonの秘密鍵を管理し、トランザクションを作成して署名する。 ウォレットを使用して、チャネル・トランザクションを送信したり、チャネル・ネットワーク内でアプリを使用したりすることができる。

A.3) プルーフ・オブ・イグジスタンス(存在証明)

1つのトランザクションタイプにより、任意のデータのハッシュを公開することができる。 システム参加者は、ヘッダーを使ってその時点でデータが存在していることを証明することができる。

B. ステート・チャネル アプリケーション

ステート・チャネルのスマート・コントラクトは、トランザクション処理能力が高いWeb上のマイクロサービスに最適である。

B.1) トール API

今日存在するほとんどのAPIは公開されていて誰でも呼び出すことができる。公開されていないものは、ユーザー名/パスワードのスキームまたは一意のアクセス・トークンで保護されている。支払いチャネルでは新しい種類のAPIが使用でき、APIに対するすべてのコール(おそらく、すべてのHTTPリクエスト)に対し一人が支払いをする。APIにアクセスするための支払いはDDoSの問題を解決するが、それは常に利用可能な高品質のAPIを構築することを容易にする。支払いを必要とするAPIの対応は、これまで不可能であったタイプのビジネスの創出には無くてはならないものであり、分散型経済の出現に重要な役割を果たす可能性がある。あるいは、それら(支払いを必要とするAPIの対応)は、情報所有者が私的なデータを公に利用できるようにするインセンティブを作りだす。

B.2) 保険付きクラウドファンディング

我々は、主要な保険コントラクトを使用して保険付きクラウドファンドを実施することができる[need cit.]。 これは、新しい橋、学校、マーケットなどの公共財に使う資金を調達するために用いられるスマートコントラクトである。支配的保証契約は、Kickstarter社の(提供する)ような従来の保証契約とは異なり、参加型ドミナント戦略になっている。製品に資金が提供されない場合、すべての参加者は自分のaeonに加えて利子が返されるので、製品を受け取ることなく流動性を低下させるということがないよう、保証される。 オラクルを使用することにより、実際に製品やサービスが提供される場合のみ、その製品やサービスの提供者は支払いを受ける、ということを保証することができる。

B.3) クロスチェーン・アトミックスワップ

クロスチェーン・アトミックスワップは、ビットコインのためにトラストレスなaeon交換を可能にする[14]、[15]。 これはハッシュロックを使用して実施できるものであり、両方のブロックチェーントランザクションを同じ値でロックする

B.4) 安定した価値資産とポートフォリオの複製

我々はスマートコントラクトを使って、現実世界の資産とほぼ同じ価格を維持するペックされた資産をプログラムすることができる。 たとえば、金と同じ価格を維持する資産を作ることができる。 合成デリバティブは、同等価値と反対価値の二つ一組で作られる。 あるユーザーが金と連動する資産を持つためには、別のユーザーが金に対して逆に動く資産を持たなければならない。例えば、アリスは1グラムの金を所有するというコントラクトをボブと結ぶことができる。契約金のうち、1グラムの金の価値のあるaeonをアリスが受け取り、残りの金をボブが受け取る。コントラクトには金の価格が測定される有効期限があり、それに応じてアリスとボブに資金が分配される。

B.5) イベント・コントラクト

イベント・コントラクトは、オラクルの判断に従って、イベントが発生した場合には支払い、イベントが発生しなかった場合には支払われない。それ自体が興味深いかどうかは別として、以下のようないくつかの異なる用途で使用できる。

a) 保険

保険を実施するために、イベント・コントラクトを使用することができる。たとえば、高価な音楽イベントのチケットは、天気が悪くなると無駄になることがある。しかし、オラクルがイベントの日に雨が降ったと判断した場合にコンサートへ行く予定だった人がお金を受け取るならば、その投資は保護されるので、その人はemotionally-adequate{感情的に適切な}選択肢を見つけることができる。さらに深刻な例では、農家はたいてい、あるシーズンに降る雨の総量に関心を持っている。我々は、彼らの作物が日照りによってしおれてしまう場合に備えて保険契約を結ぶことができる。

b) 内部通報

イベントコントラクトは機密情報の暴露を誘因するために使用することもできる。たとえば、「A社が違法農薬を使用したという情報が2017年1月24日またはそれ以前に公開された」というイベントに我々は賭けることができる。 そのような情報にアクセスできる人は、イベントが起こることに先に賭けてから公表するようにインセンティブを与えられる。

B.6) 予測市場

予測市場は、将来の出来事が起こるかどうかに賭けさせることによって機能する。 賭けの価格から、将来の可能性を予測することができる[3]、[8]、[16]。 それは、特定の価格で将来を測定する、最も正確な方法である [need cit.]。 イベントが発生すると、市場はオラクルを使って決済される。セクションII-Dで述べたように、例えば、ソフトウェアに対するアップデートのうち、どれが有益とでなり、どれが害となるかを、予測市場を使って予測することができる。また、選挙の候補者が実際にどれくらい得票できるかを見積もるためにも使用できるので、嘘や根拠のない約束をより簡単に検出することができる。
 図5 図5. 多次元予測市場

a) 多次元予測市場 

多次元予測市場は、将来起こり得る出来事間の相関関係を予測することを可能にする。たとえば、アリスがリーダーに選出されれば、ジャガイモの価格は下がり、ボブが勝利すれば価格は上がると予測できる。 Googleが今後3ヶ月間プランAを使用すればおそらく収益を増やすことができ、プランBを使用するとおそらく収益は少なくなる、といったことが分かる。 あるいは、図5のように、アリスが大統領に選出されるならば、ジャガイモの価格がかなり低くなる可能性が高いことが分かる。

B.7) 単一の価格でバッチ取引を行う市場

aeonを市場から奪おうとする攻撃者には2つのやり方がある。彼らは市場が時間的に分割されていることを利用することができる。あるいは、市場が空間的に分割されていることを利用することもできる。 •市場が空間的に分割されている場合、攻撃者は裁定取引を行う。彼は同時に両方の市場で取引を行うので、リスクが相殺され、利益を得る。 •市場が時間的に分割されている場合、攻撃者は先回り取引を行う。彼は市場に出てくる取引を読んで、直前と直後に売り注文と買い注文を出す。

図6

図6. 黒線は需要曲線、赤線は供給曲線。 赤の売りは赤の買いと同じサイズである。 縦線は、マーケットメーカーが選択した価格である。 より高い価格で買おうとする人は全員その価格で取引し、より低い価格で売ろうとする人は全員その価格で取引した。

市場を空間で結びつけるためには、誰もが同じマーケットメーカーを使わなければならない。市場を時間的に結びつけるには、単一価格で数回に分けて取引を行う必要がある。 マーケットメーカーは、彼が決めた価格を各人と約束する必要がある。誰かが、マーケットメーカーの約束に矛盾があることに気づいたら、すべての顧客が 彼のチャネルから全員離れて行ってしまうはずだ。 マーケットメーカーが適正価格を守るならば、図6に示すように、彼は同じ数の買い手と売り手をマッチさせるだろう。 さもなければ、彼は図7に似た状況に陥り、大きなリスクを負うだろう。

図7

図7. 黒は赤よりはるかに大きい。マーケットメーカーは、購入するよりも多くの株式を売っているため、多くのリスクを負っている。

IV. 実装

ほとんどの重要な概念は、既にErlangで概念実証が実施されている。これには、ブロックチェーン自体、コントラクト言語とVM、オラクルとガバナンス・メカニズム、およびコンセンサス・メカニズムの旧バージョンが含まれている。 我々はErlang/OTP使用しているが、それは多くのリクエストに同時に応答しながらもクラッシュすることのないコードを簡単に記述できるからである。世界で最も動作可能時間の長いサーバは、Erlangに基づいている。それは、30年以上産業用途に使用され、信頼性が高く安定した製品であることが証明されている。

A. 仮想マシンとコントラクト言語

バーチャル・マシンはスタックベースであり、ForthとBitcoinスクリプト言語に似ているが、後者と比べるとかなり豊富である。VMはgoto文の代わりに関数をサポートしており、そのセマンティクスを比較的簡単に分析できるようにする。VMのオペコードのリストは我々のGithubで見ることができる。さらに、Chalangと呼ばれる、より高いレベルのForthのような言語が存在し、VM用にバイトコードコンパイルされる。これはマクロと変数名をサポートするが、スタックベースの実行モデル[17]を保持する。Chalangコードの例もGithubで見ることができる。

B. ウェブ統合による導入

ウェブは最も人気のあるアプリケーション・プラットフォームである。 JSlibrariesやJSON-APIなど、Æternityブロックチェーンの中核機能にとって使いやすいWeb開発ツールを我々は提供する予定だ。

C. オープンソース・モジュール

プライベート・ブロックチェーン・コンソーシアムやその他のユースケースに簡単に再利用できるように、ソフトウェアは、コンセンサス・モジュールなどの特定のニーズに適応できるMITがライセンスを与えたモジュールで作成される。

D. ユーザビリティとUX設計

摩擦のない人間の交流は、我々の開発努力の大きな焦点となる。具体的には、誰がアイデンティティ、鍵、取引を制御するのかが明確に確認されるようにする。また、Webゲートウェイ経由で簡単にアクセスできるようにすることは、今後の開発の中心的な焦点になる。Tinderのような(左右にスワイプする)モバイル・インタフェースを介して予測市場に参加しているユーザーや、iframeを通じてウェブサイトに簡単に統合できるシンプルなWebウォレットが、新しい標準になるだろう。

V. 検討

我々は、基本的により効率的な価値移転システムを構築する方法について説明した。既述のシステムは、実際に世界規模で意思決定サービスを提供するために使うことのできる、グローバルなオラクル・マシンである。特に、セクションIIIで提案したアプリケーションはすべて、Æternityの上に簡単かつ効率的に構築することができる。 しかし、私たちのアプローチは基本的な限界と改善の道の両方を持っている。 それらについてはここで検討する。

A. 制限/限界とトレードオフ

他の分野でパフォーマンスが向上したことを考慮すると、我々のアーキテクチャで行われるトレードオフは合理的であると考えているが、Æternityは分散アプリケーションの包括的なソリューションではない。むしろ既存の技術に対する相乗的補完と見なされるべきであるが、注意すべき点がいくつかある。

A.1) オンチェイン・ステート

多くの利点があるにもかかわらず、Æternityにはプログラマブル・ステートが欠如しているので、カスタム・ステートをコンセンサスにしなければならないアプリケーションには適していない。例えば、これには通常想定されているDAOや、原資産の価値に結びついていないカスタム・ネーム・システムやサブカレンシーが含まれている。

A.2) フリー・オプション問題

アリスとボブがチャネルを持っていて、アリスがコントラクトに署名する場合、彼女は実質的にボブに自由なオプションを与えることになる。つまり、ボブは、将来いつの時点にこのコントラクトに署名して戻す(すなわちアクティブ化する)かを選択することができる。多くの場合、これは意図されたものではない。この問題を回避するために、チャネル・コントラクトはすぐには全額が有効化されない。それらは時間的または空間的に分断されている。両方の参加者は、コントラクトを小さな間隔で署名すれば、どちらのユーザーも大きなフリーオプションをもう一方のユーザーに提供することはない。たとえば、当事者たちが100 aeonを賭けたい場合、1000回に分けてサインアップし、一回につき0.1aeonずつ掛け金を増やすというやり方でもよい。これには約1000通、各方向に500通のメッセージが必要になるが、コントラクトは決してブロックチェーンに送信されないので十分に低価格である。別の例として、100日間存続する金融資産を作りたければ、1時間ごとに2400回に分けてサインアップすることができる。これには、約2400通、各方向に1200通ののメッセージが通過する必要がある。

A.3) 流動性の損失およびステート・チャネル・トポロジ

セクションII-B.1で示されているようにハッシュロックを使用してチャネルを構成する場合、いずれの仲介者も、それらを介して送信する予定の少なくとも2倍のaeonをロックアップしなければならない。たとえば、アリスとキャロルがボブを介して取引したい場合、ボブはアリスと対話するときにはキャロルとして行動し、逆も同様である。これはボブにとっては高くつくので、ほとんどの場合、代償として報酬を得るだろう。 アリスとキャロルがお互いに多くの取引をしたいと望むならば、新しいチャネルを作り、ハッシュロックを使用してアクティブなコントラクトを新しいチャネルにトラストレスに移動することで、これを回避できる。

B. 今後の課題

現在のアーキテクチャを改善する方法がいくつかある。

B.1) 機能的なコントラクト言語

合理的な将来の方向性は、機能的なパラダイムに密着した高水準の言語で試すことであろう。暗示的なスタックをトラックすることは、一般にエラーを起こしやすく、おそらく高水準の開発者向けの言語には適していない。これはむしろ簡単であるはずで、プログラムはすでに純粋な関数(modulo some environment variables{モジュロ環境変数})であることを考えると、コントラクトの開発と形式的検証の両方を大幅に簡素化するだろう。これが行われれば、コンパイル時にエラーが発生しにくく、開発者の信頼に対する依存を減らすように、VMを新しい言語と密接に関連させて修正することにも意味があるだろう。理想的には、高等言語からVMコードへの変換が、単純に査読された研究を直接書き換えたものになるであろうが、おそらく実際的な譲歩は行われなければならないだろう。

B.2) マルチパーティ・チャネル

現在、Æternity上のすべてのチャネルは2つのパーティーに限られている。ハッシュロックを使用して複数のパーティのチャネルを実現することは実際には可能だが、これは高価になる可能性がある。したがって、m-of-n解決メカニズムを使用して、n件のパーティのチャネルのためのサポートを追加できるか調査する予定である。

用語

  • Blockchain ブロックチェーン メーター式アクセスを備えた、分散型のタンパープルーフ・データベース。データベースは、ハッシュリンクされたブロックの増加するリストによって定義され、それらを追加するためのルールを持つことができる。
  • Aeon  Aeonは計算単位であり、Æternityブロックチェーンへのアクセス権を表す。譲渡可能。
  • Transaction トランザクション ユーザーからブロックチェーンへ送られるメッセージ。ユーザーが通貨を使ってブロックチェーンにアクセスする方法。
  • State Channel ステート・チャネル ブロックチェーンに記録された2人のユーザー間の関係。これは、ユーザーがaeonを送受信し、ブロックチェーンによって実行され、解決されるトラストレスなスマート・コントラクトを作することを可能にする。
  • Hash ハッシュ
 ハッシュは任意のサイズのバイナリをインプットとして取る。それにより固定サイズの出力が得られる。同じインプットは常に同じ出力に対してハッシュする。与えられた出力は、インプットを計算することができない。
  • Hashlocking ハッシュロッキング チャネルのペアを接続し、2人以上が関わるスマート・コントラクトを結ぶ方法。シークレットはそのハッシュによって参照される。シークレットが公開されると、同時に複数のチャネルを更新することができる。
  • Governance ガバナンス ブロックチェーンの将来のプロトコルを決定するための明確なプロセス。
  • Oracle オラクル この世界についてブロックチェーンの実態を知らせるメカニズム。オラクルのユーザーは、ブロックチェーンシステムの外部の出来事の結果を予測できる。
  • Value-Holder バリューホルダー aeonを所有するユーザー、またはシステム内の金融派生商品
  • Validator バリデータ バリデータとは、コンセンサス・メカニズムに参加しているユーザーのこと。Æternityの場合は、すべてのバリューホールダーが参加できる。

謝辞

Vlad、Matt、Paul、Dirk、Martin、Alistair、Devon、Benの校正作業に感謝する。 彼らや他の多くの人の洞察力ある検討に感謝する。

参考文献