Enterprise Ethereum Allianceがビジョンペーパーを発表

新しく立ち上げられたEnterprise Ethereum Alliance (EEA)が“ユーザーや利害関係者がEnterprise EthereumプロトコルをサポートしたEthereumプロトコルへの進歩を提案し実装し、まとめる”ためのビジョンペーパーを発表した。このペーパーでは、EEAはプラガブルコンセンサス、ガバナンス、相互運用性、Ethereumプロトコルのアップデート、ソースコードの実行、ストレージ、パフォーマンス最適化などの幅広いトピックを扱っている。

このビジョンペーパーはEnterprise Ethereum Allianceの設立イベントで発表された。このイベントでは30の組織がEthereumの企業でのユースケースに共に注力することが正式に発表された。このアライアンスにはMicrosoft, J.P. Morgan, Intel, Thomson Reutersといった名だたる大企業とBlockApps、String Labs、ConsenSysのようなブロックチェーンスタートアップが参加する。

短期的な目標として、EEAは、2017年の5つの目標を掲げている。

1. ネットワーク層とストレージ層のインターフェースを明確に定義し分離する効率的なモジュール化されたEthereumの実装を開発する。それは、プラガブルコンセンサスのプロトタイプであり、コンセンサスアルゴリズムを切り替えるのに必要なコードの変更を最小化する。
2. データプライバシーと許可のフレームワークと共に、見込みのあるコンセンサスアルゴリズムの実験する。
3. 企業に必要な機能と性能特性を明確にする。次のようなものが含まれる。
   1. 10のネットワークを横断する秒間100トランザクション
   2. 高いボリュームと価値を持つユースケース
   3. 高可用性/信頼性
   4. 並列化と水平スケーリング
4. 上述した内容を踏まえ、かつロードマップと会員から集めた要件を考慮し、Enterprise Ethereumのバージョン1の仕様を開発する。
5. 強固なガバナンスプロセスを活用し、手法について足並みをそろえ、合意する。

プラガブルコンセンサス

コンセンサスとは、ブロックチェーン内のノードの行為であり、トランザクションの状態に合意し、参加しているノードがアルゴリズムに合意することが前提となっている。現在のEthereumの実装はモジュール化されていないので、企業が追加の機能をコンセンサスアルゴリズムに追加する必要がある場合、Ethereumの実装をフォークすることになる。フォークするとそのフォークに対する投資は共有しにくいものになり、断片化が進む。相互運用性のニーズを満たすため、EEAはモジュールベースのコンセンサスアルゴリズムを提供しようとしている。EEAのビジョンペーパーはなぜプラガブルコンセンサスが必要なのか説明している。

共通のモジュール化された実装はEnterprise Ethereumの仕様を開発するためのコードベースを提供します。また、コンソーシアムコンセンサスアルゴリズムを実験するためのコードベースにもなります。

モジュール化するという方法に対して、EEAが考慮している点のひとつは、

アルゴリズムの仕様に関して規範的にするのではなく、ユースケースに依存して様々なアルゴリズムを使用できるようにすべきです。

Enterprise Ethereumの仕様のバージョン1

EEAの目的は単に実装を開発することではない。次のような目的で仕様を公開することだ。

開発やDevOps、マネジメントのツール、既存システムと統合するためのAPIの活用できるようにすることでエコシステムの成長を促進させることです。

仕様を提供することで、ベンダは独自の実装を提供できます。そしてインターフェースを介して相互運用をするポイントがあるので、それぞれの企業は自身の固有の要件に注力できます。互換性と相互運用性はEnterprise Ethereumだけのゴールではありません。パブリックなEthereumでも同様です。

強固なガバナンス

このアライアンスは現時点ではアメリカを拠点とした非営利の団体になろうとしており、日常の管理機能を担当する上級役員に加えて、リードエグゼクティブとボランティアの議長を募集している。

EEAは、この団体の中核は特別な関心を持つグループへの会員の参加にある、と公言している。プロトコルや設計、ロードマップや産業のグループがある。これらのグループは4つのガイドとなる原則に基づく。

1. オープンソースの標準を開発する。
2. ビルダーと実践者と共に汎用的なシステムに取り組む。
3. パブリックなEthereumとの互換性を維持する。
4. データの標準については車輪の再開発をしない。

相互運用性の強調

ブロックチェーンプロトコルの相互運用性が実現するには時間がかかるかもしれないが、EEAは相互運用性にフォーカスした要件を作っている。

1. アプリケーションの移植性とネットワークトランザクションを維持しながら、Enterprise Ethereumのさまざまなレイヤーでコンポーネントを切り替えることができる。
2. 中核となる仕様と相互運用可能な非標準拡張を提供する能力。
3. インバウンドとアウトバウンドのデータインターフェース。EVMフック。
4. パブリックなチェーンとの互換性。

相互運用性を実現するために、EEAは以下を使用して設計している。

抽象とモジュラリティ。明確なインターフェースとAPI。

また、EEAはインターフェースは一度公開したら変更するのは難しいため、相互運用性の作業については次のように見立てている。

初期段階でも致命的に重要です。

Ethereumプロトコルのアップデート

現在のEthereumプロトコルは、ひとつのノードがProof of Work(PoW)あるに基づいて最も長いチェーンのための次のブロックを選択するのに依存している。この作業の計算コストは高価だ。この方法の欠点は新しいブロックを10秒ごとにコミットするというブロックチェーンの限界があることだ。Ethereumを企業に浸透すると、サービスを何百万のユーザー向けにスケールさせる能力が、既存のプロトコルにとって脅威になる。

EEAはスケーラビリティを改善し計算コストを削減する、PoWの代替を探している。多くの手法が評価されており、将来のEthereumブロックコンセンサスアルゴリズムを形成するかもしれない。次のような手法が検討されている。

• 移譲されたProof of Stake
• Ouroboros
• Casper
• Proof of Authority

Ethereumのネットワークプロトコル層には、“ビザンチン障害を経験する可能性のあるノードのネットワークの中で状態シーケンスの全体の順序のアトミックブロードキャスト”が必要な場合がある。Ethereumのネットワークコンセンサスプロトコルには、以下を含むいくつかの提案がある。

• HoneyBadger
• HydraChain
• Tendermint

ブロックとネットワークのコンセンサスプロトコルの両方を組み合わせたアプローチもいくつかある。

• HydraChain
• Ethermint

ブロックとネットワークコンセンサスプロトコルの変更に加えて、シャーディング、並列化、ステートチャネルなどの他のスケーラビリティアプローチも検討されています。

共有デジタルインフラストラクチャの管理

Enterprise Ethereumは、分散台帳技術(DLT)を通じて組織をまとめる。新たな問題の1つはガバナンス分野だ。例えば、共有プログラムや契約をバージョン管理して更新する必要がある場合はどうすればいいのか。EEAは以下を目指す。

共有管理のための契約インターフェースとクラスの開発と既存システムの運用コードのアップデートに使える設計パターンを模索します。

信頼された計算とOracles/データフィード

実行する必要のある信頼できるコードを確保するには、いくつかの異なるアプローチがある。ひとつは主流のハードウェアを使用する方法だ。例えば、“Intel SGXは署名され、証明されたコードのみを実行できるメモリ暗号化オンシリコン回路提供します。これは、他のプロセスがアクセスできないようなっています”

また、Project Bletchleyの一部であるMicrosoft AzureのCryptletsのようなサービスを活用してセキュアなブロックチェーンミドルウエアサービスを提供することでこの問題に対処する方法もある。

信頼されたコードを実行するための安全な場所はデータフィードを分散アプリケーションやスマートコントラクトに含めようとするときに重要になる。Ethereum Enterpriseの動きではセキュアなコード実行を次のようにしようとしている。

始めはプロトコルレベルの実装に焦点を当て、時間とともに、Oracleデータ(特に重要なのは、悪意のあるデータの公開者に対するペナルティを適用する方法)の周りに意味のある設計パターンを確立することに注力することが、団体の会員から生まれることを期待しています。

ストレージ

多くの分散アプリケーションでは、文書やメディアなどのデータを格納する、という要件がある。現在、ブロックチェーンは、このようなデータを保持するための方法としては効率的ではありません。データをオフチェーンで安全に保存する方法が必要だ。この問題を解決しようとするIPFSやSwarmのようないくつかの方法がある。

性能改善と最適化

現在、Ethereumブロックチェーンは毎秒数十件のトランザクションを処理できる。企業では、ユースケースに応じてそれぞれ要件が異なる。地理的な位置に応じて柔軟性を提供し、変化する接続性の上で求められるトランザクションの数が必要だ。このような企業のニーズに対処するためEEAは次のような性能特性に注力している。

1. 特定された様々な特徴のパラメータ化して有用なベンチマークを定義する。
2. さまざまな種類のパフォーマンスを測定するためにクライアントがどのように使っているのかを明らかにする。
3. 関連するパラメータ:
   1. ノードの接続性
   2. 最適なネットワークトポロジー(接続の数とパターン)
   3. 接続の信頼性(ノード間の接続がどの程度維持されているか)
   4. 失敗のケース:ノード間の通信が途絶えるとき
   5. 安全性
   6. 活性
   7. 適切な操作に必要な健全で誠実なノードの最小数
   8. トランザクション終了までの時間
   9. ネットワークノードの総数
   10. ノードのトポロジ
   11. 伝送時間の節間距離
   12. 同期/非同期メッセージング
   13. トランザクション/秒のスループット
   14. トランザクション/ブロック送信と処理レイテンシ