[論文レビュー] Requirements for Ethereum Private Sidechains

Peter Robinson|arXiv (Cornell University)|Jun 26, 2018

Blockchain Technology Applications and Security参考文献 4被引用数 13

ひとこと要約

この論文は、強固なセキュリティ保証を提供するためのイーサリアムメインネットを活用する、許可型で認証暗号化されたブロックチェーンであるイーサリアム・プライベート・サイドチェーンを提案する。イーサリアム登録機関（ERAs）を導入して、オンデマンドでのサイドチェーンブートストラップを可能にするとともに、サイドチェーンの状態をメインネットに暗号的に束縛する安全な管理およびピン留め戦略を提示し、クォーラム、パリティ、ハイパーレッジ・ファブリックといった既存のクライアントにおける重要な欠落を解消する。

ABSTRACT

The Enterprise Ethereum Client Specification by the Enterprise Ethereum Alliance defines the requirements which Ethereum Clients offering private smart contract capabilities should comply with. This specification though ground breaking, misses some important blockchain requirements and does not fully consider the requirements of Ethereum Clients offering Private Sidechain capabilities. This paper presents the case for Private Sidechains and defines requirements to be complied with to deliver this technology. The capabilities of three blockchain clients have been analysed based on the requirements: Quorum, Parity, and Hyperledger Fabric. Quorum and Hyperledger Fabric operate as private consortium blockchains where as Parity delivers private transaction capabilities on top of Ethereum MainNet. These differing approaches has led to different strengths and weaknesses which has resulted in each client not complying with one or more key requirement. In particular, none of the reviewed blockchain clients support the ability to determine bootstrap information to establish on-demand blockchains and none of the clients support secure management and pinning from Ethereum MainNet. This paper presents Ethereum Private Sidechains and a range of technologies which allow it to deliver on complex sidechain requirements. Ethereum Registration Authorities are presented, which allow entities which have not previously interacted to securely obtain information to bootstrap a sidechain, and a Management and Pinning strategy is described which allows the state of a sidechain to be securely pinned to Ethereum MainNet without compromising privacy.

研究の動機と目的

• 既存の企業向け実装における、標準化され、安全でオンデマンドのセットアップメカニズムが不足しているプライベート・イーサリアム・ブロックチェーンの問題を解決すること。
• 分散化の原則を損なわず、強固なプライバシー、完全性、信頼性を確保するためのイーサリアム・プライベート・サイドチェーンの要件を定義すること。
• イーサリアム・メインネットを信頼の基盤として用い、イーサリアム登録機関（ERAs）を通じて、安全でオンデマンドのプライベート・サイドチェーンの構築を可能にすること。
• プライベート・データを露呈せずに、サイドチェーンの状態を暗号的にメインネットに固定する安全な管理およびピン留め戦略を提供すること。
• クォーラム、パリティ、ハイパーレッジ・ファブリックにおけるブートストラップの発見、安全なピン留め、クロスチェーン相互運用性に関する、重要なギャップを特定し、それを埋めること。

提案手法

• イーサリアム・メインネットにデプロイされたスマートコントラクトとしてのイーサリアム登録機関（ERAs）を提案し、ドメイン名と組織メタデータを用いた、信頼できない環境下でもオンデマンドでプライベート・サイドチェーンを発見・ブートストラップ可能にする。
• 認証暗号化と否認不能性の保証を用いて、サイドチェーンの状態がイーサリアム・メインネットに暗号的にピン留めできる安全な管理およびピン留め戦略を設計する。
• プライベート・サイドチェーンのコンセンサスと、イーサリアム・メインネットのコンセンサスメカニズムとの両方をサポートするモジュラーなコンセンサスアーキテクチャを設計する。
• プライバシーと完全性を保持したまま、プライベート・サイドチェーン間での安全で許可型のデータ交換を可能にする、サイドチェーン間通信プロトコルを定義する。
• 構成、アーカイブ、レート制限メカニズムを含む、サイドチェーンのライフサイクル管理のフレームワークを確立する。これによりスパム防止と運用のレジリエンスが確保される。
• 新たな要件（例：SC-4a-Pinning、SC-3a-SidechainFindOrEstablishmentApi）を追加し、Enterprise Ethereum Client Specificationを拡張して、サイドチェーン機能を形式化する。

実験結果

リサーチクエスチョン

• RQ1 プライベート・イーサリアム・サイドチェーンは、当事者間の事前の協調や信頼を必要とせずに、どのようにオンデマンドで構築できるか？
• RQ2 プライベート・データを漏洩させることなく、プライベート・サイドチェーンの状態がイーサリアム・メインネットに暗号的に束縛され続ける仕組みは何か？
• RQ3 クォーラム、パリティ、ハイパーレッジ・ファブリックといった既存のクライアントが、安全でスケーラブルかつ相互運用可能なプライベート・サイドチェーンを満たすために失敗する理由は何か？
• RQ4 イーサリアム・メインネットを信頼の根拠として用い、分散型で信頼のないプライベート・サイドチェーンの発見メカニズムをどのように実装できるか？
• RQ5 イーサリアムエコシステム内での安全でスケーラブルかつ合成可能なプライベート・サイドチェーンをサポートするには、どのようなアーキテクチャ的およびプロトコルレベルの強化が必要か？

主な発見

• 調査対象のクライアント（クォーラム、パリティ、ハイパーレッジ・ファブリック）のいずれにも、オンデマンドでのサイドチェーン作成に必要なブートストラップ情報の発見がサポートされておらず、動的でプライベートなブロックチェーン展開において深刻な欠落が生じている。
• どのクライアントも、イーサリアム・メインネットへのサイドチェーン状態の安全な管理およびピン留めを完全にサポートしておらず、サイドチェーンの状態改ざんや監査可能性の喪失のリスクが生じている。
• イーサリアム登録機関（ERAs）は、ドメイン名とサイドチェーンメタデータの間の検証済みで暗号的に署名されたマッピングをメインネットに発行することで、信頼できない環境下でもオンデマンドでのサイドチェーンセットアップを可能にする。
• 提案された安全なピン留め戦略により、認証暗号化と否認不能性を用いて、プライベート・データを露呈せずにサイドチェーンの状態をメインネットに固定できる。完全性が保証される。
• クォーラムとハイパーレッジ・ファブリックはプライベートコンセンサスと認証暗号化をサポートしているが、発見およびピン留めのサポートがなく、パリティはメインネットでのプライベート取引は可能だが、完全なサイドチェーン機能はサポートしていない。
• 分析の結果、現在の実装は、特にサイドチェーン発見（BC-3a）、ピン留め（SC-4a）、マルチサイドチェーンサポート（SC-4g）の分野で、Enterprise Ethereum Client Specificationの要件を満たしていないことが判明した。