仮想通貨にライバルはいないの？Corda、Fabric、Ethereumの比較(翻訳記事)
ビットコインから資金がアルトに流れている相場ですが、いつまでも続くわけではないので、そろそろ注意した方がいいころかもしれません！
チャートはこちら
XEMを購入することができるZaifへの登録はこちら
Zaifへの登録手順は過去記事を参考にしてください！
さて、Bitflyerに続き、CoincheckでもCMが始まり、
仮想通貨が世間にかなり知られるようになってきました。
ビットコインが数百円から200万円にも上がってきたこともあり、
どの通貨もどこまででも上がると煽る人も出てきてしまっています。
完全に投資(投機？)商品になってしまったようにも見える仮想通貨。
妄信的に分散台帳技術すごい！仮想通貨は買いだ！！という人がいますが、
分散台帳技術は仮想通貨だけじゃないという話をしたいと思います。
有名なブロックチェーン技術にはHyperledgerのFabricとCordaがあります。
Hyperledger
2016年にLinux Foundationのプロジェクトとして始動した分散型台帳技術プロジェクトです。
中心メンバーにはIT巨人のIBMだけでなく、日本の誇る大企業である日立製作所やNECもいます！
2016年にLinux Foundationのプロジェクトとして始動した分散型台帳技術プロジェクトです。
中心メンバーにはIT巨人のIBMだけでなく、日本の誇る大企業である日立製作所やNECもいます！
Corda
金融取引に照準を絞った分散台帳を、世界の金融機関で一緒になって作っていこう！というプロジェクトです。
JPモルガンやドイツ銀行、三井住友銀行、野村證券などがメンバーです。
金融取引に照準を絞った分散台帳を、世界の金融機関で一緒になって作っていこう！というプロジェクトです。
JPモルガンやドイツ銀行、三井住友銀行、野村證券などがメンバーです。
今回はこれらと仮想通貨の代表格、Ethereumを比較する以下の論文の翻訳をしてみました。
Comparison of Ethereum, Hyperledger Fabric and Corda
1. EthereumとHyperledger FabricそしてCorda
2. 3つの異なるフレームワーク
Hyperledger Fabric、R3 Corda（以下、それぞれFabricとCorda）とEthereumそれぞれのホワイトペーパーから、これらのフレームワークは、応用可能分野という点で全く異なるビジョンを念頭に置いていることが明らかです。 Fabric とCorda の開発はともに、具体的なユースケースをもとに進められていますが、Cordaのユースケースは金融サービス業界におけるものです。
ゆえに、Cordaは金融サービス業界を応用分野と位置付けています。
これとは対照的に、Fabricは、バンキングやヘルスケアからサプライチェーンまで、さまざまな業界で利用可能なモジュール式で拡張可能なアーキテクチャを提供することを目指しています。
また、Ethereumは、特定の応用分野を持ちません。Fabricとは対照的に、モジュール化されているだけでなく、あらゆる種類のトランザクションやアプリケーションに対応する汎用プラットフォームを提供します。
ゆえに、Cordaは金融サービス業界を応用分野と位置付けています。
これとは対照的に、Fabricは、バンキングやヘルスケアからサプライチェーンまで、さまざまな業界で利用可能なモジュール式で拡張可能なアーキテクチャを提供することを目指しています。
また、Ethereumは、特定の応用分野を持ちません。Fabricとは対照的に、モジュール化されているだけでなく、あらゆる種類のトランザクションやアプリケーションに対応する汎用プラットフォームを提供します。
3. ピアの参加
従来の中央データストレージでは、唯一所有者だけが基礎となるデータベースのコピーを台帳のような形で保有します。したがって、この所有者は、どのデータを、誰に公開するのかを制御します。
DLTの出現により、複数の人々が基盤となるデータベースのコピーの保有を可能にし、誰しもに公開する分散型データストレージがこの構造を根本的に変化させました。
分散データストレージに参加するすべての人々は、いわゆるノードやピアのネットワークを形成します。分散型データストレージの性格上、すべてのノードが共通の真実（例えば、 1つのノードが行った変更をネットワーク内の他のすべてのピアノードに伝えるといった台帳の正確性）を確認し合わなければなりません。この共通の真実へ達することを、ノード間のコンセンサスと呼びます。以下でコンセンサスについて説明します。
コンセンサスへの参加に関しては、permissionlessとpermissionedの2つのモードがあります。
コンセンサスへの参加がpermissionlessの場合、誰でもネットワークに参加することができます。パブリックブロックチェーンとしてのEthereumがこのモードです。
一方、参加がpermissionedの場合、参加者は事前に選択され、彼らのみネットワークへのアクセスが可能となります。FabricとCordaがこのモードです。
permissionlessやpermissionedといった参加のモードは、コンセンサス達成の方法に大きく影響します。
DLTの出現により、複数の人々が基盤となるデータベースのコピーの保有を可能にし、誰しもに公開する分散型データストレージがこの構造を根本的に変化させました。
分散データストレージに参加するすべての人々は、いわゆるノードやピアのネットワークを形成します。分散型データストレージの性格上、すべてのノードが共通の真実（例えば、 1つのノードが行った変更をネットワーク内の他のすべてのピアノードに伝えるといった台帳の正確性）を確認し合わなければなりません。この共通の真実へ達することを、ノード間のコンセンサスと呼びます。以下でコンセンサスについて説明します。
コンセンサスへの参加に関しては、permissionlessとpermissionedの2つのモードがあります。
コンセンサスへの参加がpermissionlessの場合、誰でもネットワークに参加することができます。パブリックブロックチェーンとしてのEthereumがこのモードです。
一方、参加がpermissionedの場合、参加者は事前に選択され、彼らのみネットワークへのアクセスが可能となります。FabricとCordaがこのモードです。
permissionlessやpermissionedといった参加のモードは、コンセンサス達成の方法に大きく影響します。
4. コンセンサス
Ethereum
Ethereumでは、すべての参加者は、ある特定の取引の当事者でなくても、取引の行われた順番にすべてコンセンサスに達しなければなりません。
取引の順序は、台帳の一貫性に非常に重要となります。取引の順序が決定的に確立できない場合、二重支出発生の可能性が生じます。つまり、2つの並行した取引により同一のコインを異なる受取人に送信して、不正にお金を得たということです。ネットワークには不信と匿名の人々が関与することもあるので、二重支出を行おうとする悪意の参加者から台帳を保護するために、コンセンサスの仕組みが必要なのです。
現在のEthereumでは、このコンセンサスメカニズムは、proof-of-work（PoW）スキームに基づくマイニングによって確立されています。すべての参加者は共通の台帳に同意する必要があり、すべての参加者は今まで記録されたすべての取引データにアクセスできます。しかし、結果として、PoWスキームはトランザクション処理のパフォーマンスに悪影響を及ぼしています。
また、台帳に記録されたデータに関して、記録自体は匿名化されていますが、すべての参加者がアクセス可能であるため、高いプライバシーを必要とするアプリケーションでは問題となってしまいます。
Ethereumとは対照的に、FabricとCordaのコンセンサスの解釈はより検討されており、PoWまたはその派生アルゴリズムに基づくマイニングだけの利用だけではありません。 permissionedモードで動作するため、FabricとCordaはより細かい記録へのアクセス制御を提供し、プライバシーの強化を図っています。 さらに、取引に参加している当事者のみがコンセンサスに達すればよいため、Ethereumよりパフォーマンスが向上しています。
取引の順序は、台帳の一貫性に非常に重要となります。取引の順序が決定的に確立できない場合、二重支出発生の可能性が生じます。つまり、2つの並行した取引により同一のコインを異なる受取人に送信して、不正にお金を得たということです。ネットワークには不信と匿名の人々が関与することもあるので、二重支出を行おうとする悪意の参加者から台帳を保護するために、コンセンサスの仕組みが必要なのです。
現在のEthereumでは、このコンセンサスメカニズムは、proof-of-work（PoW）スキームに基づくマイニングによって確立されています。すべての参加者は共通の台帳に同意する必要があり、すべての参加者は今まで記録されたすべての取引データにアクセスできます。しかし、結果として、PoWスキームはトランザクション処理のパフォーマンスに悪影響を及ぼしています。
また、台帳に記録されたデータに関して、記録自体は匿名化されていますが、すべての参加者がアクセス可能であるため、高いプライバシーを必要とするアプリケーションでは問題となってしまいます。
Ethereumとは対照的に、FabricとCordaのコンセンサスの解釈はより検討されており、PoWまたはその派生アルゴリズムに基づくマイニングだけの利用だけではありません。 permissionedモードで動作するため、FabricとCordaはより細かい記録へのアクセス制御を提供し、プライバシーの強化を図っています。 さらに、取引に参加している当事者のみがコンセンサスに達すればよいため、Ethereumよりパフォーマンスが向上しています。
Fabric
Fabricにおけるコンセンサスは幅広く、取引をネットワークに提示することから台帳に記録することまで、取引フロー全体を網羅しています。
さらに、ノードはコンセンサスに達する過程で異なる役割とタスクを実行します。Ethereumではコンセンサスの達成に参加するノードの役割やタスクが同じであることから、対照的であると言えます。
Fabricでは、ノードはクライアント、ピア、またはオーダラーであるかにより区別されます。クライアントはエンドユーザーに代わり、トランザクションを生成し、実行します。 クライアントはピアやオーダラーと通信します。
ピアは、台帳を維持する役目をし、オーダーからの更新メッセージを受け取り、新たな取引を台帳に反映します。
エンドーサーは特別なタイプのピアであり、ある取引が必要十分条件（例えば、必要な署名の提供）を満たしているかどうかをチェックして、取引の正しさを裏打ちします。
オーダラーは、取引を含むメッセージを送ることができるクライアントおよびピアに通信チャネルを提供します。 特にコンセンサスに関して、通信チャネルにより、接続されたすべてのピアがまったく同じメッセージをまったく同じ論理的な順序で送ることが保証されます。
しかしここで、信頼できないオーダラーが多く採用されてしまった場合に、メッセージの送信に障害が発生する可能性が浮上します。結果として、障害に関わらず、コンセンサスに達するためにはコンセンサスアルゴリズムの使用が必須です。例えば、メッセージの順序が矛盾した場合、分散型台帳の複製の障害が許容されます。
Fabricで、使用するアルゴリズムは「pluggable」です。つまり、アプリケーション固有の条件に応じて、さまざまなアルゴリズムを使用することができます。例えば、先に例で挙げたようなランダムまたは悪意のある複製の障害に対処するためには、ビザンチンフォールトトレラント（BFT）アルゴリズムの変形を使用可能です。さらに、チャネルはメッセージフローをわけており、クライアントには接続しているチャネルのメッセージと関連するトランザクションのみが表示され、他のチャネルは認識しません。
このように、トランザクションへのアクセスは関係者だけに限定され、コンセンサスにはEthereumのように台帳段階ではなく、取引段階で達されます。
先に説明したノードの役割に関して、トランザクションフローの流れを説明します。クライアントは、台帳の更新を開始するため、接続されたエンドーサーにトランザクションを送信します。 すべてのエンド―サーは、提示されたトランザクションに同意しなければならないため、提示された台帳の更新に関して何らかの合意に達する必要があります。 クライアントはすべてのエンドーサーの承認を逐次収集します。 承認されたトランザクションは、ここで接続しているオーダラーに送信されます。 その後、トランザクションは、トランザクションを反映させるために台帳を保有するピアに転送されます。
このようにして、Fabricはコンセンサスやトランザクションへのアクセスを細かく制御できるため、スケーラビリティとプライバシーの向上を達成しています。
さらに、ノードはコンセンサスに達する過程で異なる役割とタスクを実行します。Ethereumではコンセンサスの達成に参加するノードの役割やタスクが同じであることから、対照的であると言えます。
Fabricでは、ノードはクライアント、ピア、またはオーダラーであるかにより区別されます。クライアントはエンドユーザーに代わり、トランザクションを生成し、実行します。 クライアントはピアやオーダラーと通信します。
ピアは、台帳を維持する役目をし、オーダーからの更新メッセージを受け取り、新たな取引を台帳に反映します。
エンドーサーは特別なタイプのピアであり、ある取引が必要十分条件（例えば、必要な署名の提供）を満たしているかどうかをチェックして、取引の正しさを裏打ちします。
オーダラーは、取引を含むメッセージを送ることができるクライアントおよびピアに通信チャネルを提供します。 特にコンセンサスに関して、通信チャネルにより、接続されたすべてのピアがまったく同じメッセージをまったく同じ論理的な順序で送ることが保証されます。
参加モードにはpermissionlessまたはpermissionedがあり、このモードがコンセンサス達成の方法に大きく影響します。
しかしここで、信頼できないオーダラーが多く採用されてしまった場合に、メッセージの送信に障害が発生する可能性が浮上します。結果として、障害に関わらず、コンセンサスに達するためにはコンセンサスアルゴリズムの使用が必須です。例えば、メッセージの順序が矛盾した場合、分散型台帳の複製の障害が許容されます。
Fabricで、使用するアルゴリズムは「pluggable」です。つまり、アプリケーション固有の条件に応じて、さまざまなアルゴリズムを使用することができます。例えば、先に例で挙げたようなランダムまたは悪意のある複製の障害に対処するためには、ビザンチンフォールトトレラント（BFT）アルゴリズムの変形を使用可能です。さらに、チャネルはメッセージフローをわけており、クライアントには接続しているチャネルのメッセージと関連するトランザクションのみが表示され、他のチャネルは認識しません。
このように、トランザクションへのアクセスは関係者だけに限定され、コンセンサスにはEthereumのように台帳段階ではなく、取引段階で達されます。
先に説明したノードの役割に関して、トランザクションフローの流れを説明します。クライアントは、台帳の更新を開始するため、接続されたエンドーサーにトランザクションを送信します。 すべてのエンド―サーは、提示されたトランザクションに同意しなければならないため、提示された台帳の更新に関して何らかの合意に達する必要があります。 クライアントはすべてのエンドーサーの承認を逐次収集します。 承認されたトランザクションは、ここで接続しているオーダラーに送信されます。 その後、トランザクションは、トランザクションを反映させるために台帳を保有するピアに転送されます。
このようにして、Fabricはコンセンサスやトランザクションへのアクセスを細かく制御できるため、スケーラビリティとプライバシーの向上を達成しています。
Corda
Fabricと同様に、Cordaにおいても取引段階で当事者によりコンセンサスに達します。 ここでいうコンセンサスは、トランザクションの妥当性とトランザクションの一意性です。
妥当性の確認はトランザクションに関連するスマートコントラクトコード（スマートコントラクトの説明は以下に）を実行することにより、必要な署名をチェックし、参照されているトランザクションが有効であることを保証することで行われます。
一意性は、トランザクションの入力状態に関係します。 具体的には、問題のトランザクションがすべての入力状態において固有であることが保証されなければならないのです。 言い換えれば、同じ状態であるトランザクションは1つしか存在しません。 この一意性の検証は、二重支出を防ぐためです。 一意性はノータリーノードと呼ばれる参加者の間でコンセンサスに達しますが、採用アルゴリズムはFabricと同様で「pluggable」です。 したがって、CordaでもBFTアルゴリズムの使用が可能です。
妥当性の確認はトランザクションに関連するスマートコントラクトコード（スマートコントラクトの説明は以下に）を実行することにより、必要な署名をチェックし、参照されているトランザクションが有効であることを保証することで行われます。
一意性は、トランザクションの入力状態に関係します。 具体的には、問題のトランザクションがすべての入力状態において固有であることが保証されなければならないのです。 言い換えれば、同じ状態であるトランザクションは1つしか存在しません。 この一意性の検証は、二重支出を防ぐためです。 一意性はノータリーノードと呼ばれる参加者の間でコンセンサスに達しますが、採用アルゴリズムはFabricと同様で「pluggable」です。 したがって、CordaでもBFTアルゴリズムの使用が可能です。
5. スマートコントラクト
「スマートコントラクト」という用語は、インテリジェントに自分の代わりに行動する何らかの契約のことだと思わせてしまうため、所見の人に対し誤解を与えやすいです。しかしながら、コントラクトは曖昧であり、直観的に法的問題に関連していると思われがちです。ここでいうコントラクトは、例えば、人工知能によって駆動されるというような意味でスマートだというわけではなく、法的拘束力のある義務や権利をコードしているというわけでもありません。
Clarkらは、「スマートコントラクト」という用語がの2つの異なる意味を強調して、誤解を防ぐ用語を提案しています。最初のものはスマートコントラクトコード、2番目をスマートな法的契約と表現しています。
スマートコントラクトコードは、単にプログラミング言語で書かれたソフトウェアです。 スマートコントラクトはソフトウェアエージェントまたは代理人として、自動で一定の義務を果たし、権利を行使し、分散台帳内の資産を管理します。
したがって、法的な正当性は不明確かもしれませんが、現実世界での契約ロジックをモデル化またはエミュレートするコードを実行することで、スマートコントラクトが分散台帳に関するタスクと責任を負うことができます。
すべての分散台帳技術には、スマートコントラクトコードがあり、FabricはGoやJava、EthereumはSolidity、CordaはJavaやKotlinで書かれています。Fabricにおいては、「チェーンコード」という用語がスマートコントラクトの代わりに用いられます。例としては、トランザクションの有効性を保証するための、Cordaのコンセンサスメカニズムにおけるスマートコントラクトコードの使用が挙げられます。
しかしFabricとEthereumの間に顕著な違いがある一方、Cordaは「スマートコントラクト」という用語の第2の意味に関連しています。
Cordaでは、スマートコントラクトはコードで構成されているだけでなく、法的な散文体も記載可能です。 つまり、上記のスマートな法定契約とは、スマートコントラクトコードで表現され実装されるように考案された法的な散文体を意味します。 このような機能を実装した背後には、関連する法的な散文体に根ざしたコードの合法性を与えるといった狙いがあります。 そのような構造をRicardian Contract と呼びます。
この点で、Cordaは非常に規制の多い金融サービス産業をターゲットとするために設計されたことがわかります。
FabricとEthereumにはこのような機能はありません。
Clarkらは、「スマートコントラクト」という用語がの2つの異なる意味を強調して、誤解を防ぐ用語を提案しています。最初のものはスマートコントラクトコード、2番目をスマートな法的契約と表現しています。
スマートコントラクトコードは、単にプログラミング言語で書かれたソフトウェアです。 スマートコントラクトはソフトウェアエージェントまたは代理人として、自動で一定の義務を果たし、権利を行使し、分散台帳内の資産を管理します。
したがって、法的な正当性は不明確かもしれませんが、現実世界での契約ロジックをモデル化またはエミュレートするコードを実行することで、スマートコントラクトが分散台帳に関するタスクと責任を負うことができます。
スマートコントラクトコードは、プログラミング言語で書かれたソフトウェアです。
すべての分散台帳技術には、スマートコントラクトコードがあり、FabricはGoやJava、EthereumはSolidity、CordaはJavaやKotlinで書かれています。Fabricにおいては、「チェーンコード」という用語がスマートコントラクトの代わりに用いられます。例としては、トランザクションの有効性を保証するための、Cordaのコンセンサスメカニズムにおけるスマートコントラクトコードの使用が挙げられます。
しかしFabricとEthereumの間に顕著な違いがある一方、Cordaは「スマートコントラクト」という用語の第2の意味に関連しています。
Cordaでは、スマートコントラクトはコードで構成されているだけでなく、法的な散文体も記載可能です。 つまり、上記のスマートな法定契約とは、スマートコントラクトコードで表現され実装されるように考案された法的な散文体を意味します。 このような機能を実装した背後には、関連する法的な散文体に根ざしたコードの合法性を与えるといった狙いがあります。 そのような構造をRicardian Contract と呼びます。
この点で、Cordaは非常に規制の多い金融サービス産業をターゲットとするために設計されたことがわかります。
FabricとEthereumにはこのような機能はありません。
6. ビルトイン通貨
さらに、事前に定義された標準に準拠したスマートコントラクトを展開することでカスタムユースケース用のデジタルトークンを作成できます。この機能を利用することで、独自の通貨や資産を作り出すことができます。
FabricとCordaでは、マイニングによってコンセンサスに達することはないため、暗号通貨は不要です。 ただし、Fabricでは、ネイティブ通貨やチェーンコード付きのデジタルトークンを開発することは可能です。
Cordaでは、デジタル通貨やトークンの作成は行われません。
7. まとめ：カスタマイズされたプラットフォームか汎用プラットフォームか
要約すると、今回記載した分散台帳技術には連続性がありました。FabricとEthereumはどちらにも、非常に柔軟性がありますが、異なる側面があります。
Ethereumの強力なスマートコントラクトエンジンは、文字通りあらゆる種類のアプリケーションの汎用プラットフォームになりえます。しかし、Ethereumのpermissionlessモードと完全な透明性は、パフォーマンスのスケーラビリティとプライバシーを犠牲にしてしまっています。
Fabricは、permissionedモード、特にBFTアルゴリズムと詳細なアクセス制御を使用することで、パフォーマンスのスケーラビリティとプライバシーの問題を解決しました。さらに、モジュラアーキテクチャにより、Fabricを多数のアプリケーションにカスタマイズすることができ、多目的なツールボックスに類することができます。
Cordaは全く別の場所に位置しています。 Cordaは意図的に金融サービス業界の分散台帳技術として設計されています。 最も顕著なのは、法を考慮してスマートコントラクトを強化することで、非常に規則の多い金融業界の参入を狙っていることです。
金融サービス取引だけに焦点を当てているCordaは、Fabricと比較してアーキテクチャ設計を簡素化しています。 したがって、Cordaは枠にとらわれないものが提供できるかもしれません。 しかし、Fabricはモジュール性のため、Cordaの特徴に似せることができます。
また、CordaをHyperledgerプロジェクトに統合しようという試みもあり、今後CordaはFabricの競合相手ではなく、補完的なものとして捉えるべきかもしれません。
Ethereumの強力なスマートコントラクトエンジンは、文字通りあらゆる種類のアプリケーションの汎用プラットフォームになりえます。しかし、Ethereumのpermissionlessモードと完全な透明性は、パフォーマンスのスケーラビリティとプライバシーを犠牲にしてしまっています。
Fabricは、permissionedモード、特にBFTアルゴリズムと詳細なアクセス制御を使用することで、パフォーマンスのスケーラビリティとプライバシーの問題を解決しました。さらに、モジュラアーキテクチャにより、Fabricを多数のアプリケーションにカスタマイズすることができ、多目的なツールボックスに類することができます。
Cordaは全く別の場所に位置しています。 Cordaは意図的に金融サービス業界の分散台帳技術として設計されています。 最も顕著なのは、法を考慮してスマートコントラクトを強化することで、非常に規則の多い金融業界の参入を狙っていることです。
金融サービス取引だけに焦点を当てているCordaは、Fabricと比較してアーキテクチャ設計を簡素化しています。 したがって、Cordaは枠にとらわれないものが提供できるかもしれません。 しかし、Fabricはモジュール性のため、Cordaの特徴に似せることができます。
また、CordaをHyperledgerプロジェクトに統合しようという試みもあり、今後CordaはFabricの競合相手ではなく、補完的なものとして捉えるべきかもしれません。
コメント
コメントを投稿