1 © LayerX Inc. Version 2.0.0 August, 2020 LayerX Inc. エンタープライズ向けブロックチェーン基盤比較レポート 基本編

2 © LayerX Inc. 1. LayerX Enterprise blockchain Analysis Framework(LEAF)について 2. ブロックチェーンの基本設計 3. 基本設計の整理 4. 基本設計の比較 5. 公開資料・お問い合わせ 目次

3 © LayerX Inc. LayerX Enterprise blockchain Analysis Frameworkについて 1

4 © LayerX Inc. LayerX Enterprise blockchain Analysis Framework (LEAF) プライバシー (秘匿性/匿名性) インター オペラビリティ ブロックチェーンを用いたシステムの設計の検討コスト削減 LEAFは異なるエンタープライズ向けブロックチェーン基盤を 3つの観点で分析するフレームワーク 1. LEAFについて LayerX Enterprise blockchain Analysis Framework (LEAF) 基本設計

5 © LayerX Inc. 1. LEAFについて LayerX Enterprise blockchain Analysis Framework (LEAF) LayerX Enterprise blockchain Analysis Framework (LEAF) プライバシー (秘匿性/匿名性) インター オペラビリティ 基本設計 基本設計の整理 （トランザクションフローの5フェーズ分析、ノード定義） ノード分類 データ共有範囲 データモデル 各フェーズで実行される処理 基本設計の比較 セキュリティ コンセンサス（故障耐性・ネットワークモデル） コンセンサス以外 状態遷移ロジック の柔軟性 1回の状態遷移で読み書きできる状態データの範囲 状態遷移ロジックの表現力 状態遷移ロジックの更新難易度

6 © LayerX Inc. ブロックチェーンの基本設計について 2

7 © LayerX Inc. トランザクション 状態データの変化を引き起こす命令をトランザクション(TX)と呼ぶ。上図では (1)AからBへの送金指示 (2)Dの口座の凍結指示等の命令 によって別の状態データに変化させている。 口座所有者 残高 ステータス A 30,000 有効 B 10,000 有効 C 2,000 有効 D 1,000 有効 口座所有者 残高 ステータス A 25,000 有効 B 15,000 有効 C 2,000 有効 D 1,000 凍結済み (1)A→Bへ5000送金 (2)Dを凍結 ブロックチェーンのデータはある時点での断面としての状態データと 状態データの変化を引き起こす命令 (トランザクション) によって構成される 2. ブロックチェーンの基本性質について ブロックチェーンにおけるデータレプリケーション

8 © LayerX Inc. 基本設計の整理 3

9 © LayerX Inc. 提案 クライアントまたは ノードが状態遷移に対 応するトランザクショ ンを作成し、コンセン サスノードに送信す る。 Phase 1 コンセンサスノードは 送信されたトランザク ションを何らかのルー ルで検証して合意形成 し、その証跡を残す。 コンセンサス コンセンサスノードは コンセンサスで合意さ れたトランザクション の列を指定したノード に送信する。 配布 各ノードは配布された トランザクションの列 を何らかのルールに 従って解釈、検証す る。 解釈・検証 各ノードは解釈・検証 の結果をもって、自身 の状態データを更新す る。 更新 ブロックチェーンのトランザクションフローを 5つのフェーズに分解 3. 基本設計の整理 トランザクションフローの分析フレームワーク Phase 2 Phase 3 Phase 4 Phase 5

10 © LayerX Inc. Node A Node C Node B 1- (1). 提案 TXを作成・検証した上で署名し、NodeBに送信 1- (2). 提案 TXをContractで検証した上で署名し、NodeAに送信 1- (3). 提案 Notaryに署名リクエスト 2. コンセンサス inputsの未消費チェックを行った上でTXHashに署名する Validating Notaryの場合は状態遷移と署名検証の検証も行う 3-(1). 配布 Notary署名済みTXHashを Node Aに送信 3-(2). 配布 Notary署名済みTXHashをNode Bに送信 4&5. 解釈・検証&更新 署名を検証し、 自身の状態を更新 TXを共有されないNode Cordaのトランザクションフロー図 3. 基本設計の整理 Cordaのトランザクションフロー 4&5. 解釈・検証&更新 署名を検証し、 自身の状態を更新 Validating Notary(VN) Non-validating Notary(NN) or

11 © LayerX Inc. Endorser Endorser Peer Peer Peer Peer 1- (1). 提案 EndorserにTXのProposalを送信 1- (3). 提案 Endorsed Proposal Response を返却 1- (2). 提案 EndorserがChaincodeをシュミレートして Read-Write Setを生成 1- (4). 提案 Endorserからの Responseを検証 1- (5). 提案 TXをOrdererに送信 2. コンセンサス TXの順番を決め、Blockを作成 3. 配布 OrganizationのLeader Peerに Blockを配布 4&5. 解釈・検証&更新 各PeerがEndorsement Policyと KeyのVersionを検証し、 World Stateを更新する 1- (1). 提案 EndorserにTXのProposalを送信 1- (2). 提案 EndorserがChaincodeをシュミレートして Read-Write Setを生成 Client Hyperledger Fabric(HLF)のトランザクションフロー図 3. 基本設計の整理 Hyperledger Fabricのトランザクションフロー Orderer

12 © LayerX Inc. 1- (1). 提案 TXをリクエスト Node 1- (2). 提案 TXをリクエストの ブロードキャスト 3. 配布 Blockの配布 2. コンセンサス Leader・Validatorsによる Blockの作成と署名 4&5. 解釈・検証&更新 TXの実行とStateの更新 1- (2). 提案 TXをリクエストの ブロードキャスト 4&5. 解釈・検証&更新 TXの実行とStateの更新 1- (2). 提案 TXをリクエストの ブロードキャスト Client Quorumのトランザクションフロー図 3. 基本設計の整理 Quorumのトランザクションフロー Node Leader Validator Validator Validator

13 © LayerX Inc. Corda HLF ノード分類・定義 コンセンサスプロトコルのアルゴリズムを実行する ノード（②コンセンサス、③配布） 全データを取得し、プロトコル・アプリケーション レベルの状態遷移の検証を行うノード （①提案、④解釈・検証、⑤更新） データの一部を取得し、プロトコル・アプリケーション レベルの状態遷移の検証のうち一部を実行するノード （①提案、④解釈・検証、⑤更新） Notary Orderer Quorum Validator - Peer Node Node - - コンセンサス ノード フルノード ライトノード データ共有範囲 各ノードで 異なる 状態データ 全ノードで 共通の 状態データ 全ノードで 共通の 状態データ HLF、Quorumは全ノードで共通データを永続化するが、 Cordaは各ノードの永続化データは異なる。Cordaにはフルノードが存在しない。 3. 基本設計の整理 各基盤のノード分類とデータ共有範囲の比較

14 © LayerX Inc. Corda NN 提案フェーズに 実行されるロジック コンセンサスフェーズに 実行されるロジック 解釈・検証フェーズに 実行されるロジック Corda VN HLF Quorum Flow Chaincode なし 二重消費の検証 ● Contract ● requiredSignersの 署名検証 ● 二重消費の検証 なし ● nonce等の検証 ● Smart Contract ● requiredSignersとNotaryの署名検証 ● Contractの実行 ● Endorsement Policyの署名検証 ● State Keyの Versionの検証 ● nonce等の検証 ● Smart Contract HLFはChaincodeのロジックの検証をコンセンサスと解釈・検証フェーズで行わない。 Quourm、Corda (VN) は両フェーズでSmart Contract、Contractのロジック検証を行う。 Corda (NN)はコンセンサスフェーズでContractのロジック検証を行わない。 3. 基本設計の整理 フェーズごとの実行ロジックとデータ共有範囲の比較

15 © LayerX Inc. 基本設計の比較 4

16 © LayerX Inc. Raft: CFT 2F+1 Kafka: CFT 2F+1 Solo: なし IBFT: BFT 3F+1 Clique PoA: BFT 2F+1 Raft: CFT 2F+1 Raft: 部分的同期 Kafka: 部分的同期 Solo: なし IBFT: 同期 Clique PoA: 同期 Raft: 部分的同期 コンセンサス以外 Endorsement Policyで定義 したEndorserが故障 し,Liveness,ないしValidity が失われる - CordaのOSS版は、Enterprise版と異なり、コンセンサスの故障耐性がない。また、Cordaでは Livenessを失わせる攻撃が可能で、NNに限ってはValidityを失わせる攻撃も可能である。 HLFでは、コンセンサスノード以外の故障によりValidityが失われる場合がある。 Quorumはコンセンサスの故障耐性があり、コンセンサス以外の脆弱性も存在しない。 4. 基本設計の比較 セキュリティ コンセンサス 故障耐性 ネットワーク モデル OSS版: なし Enterprise版・Raft: 2F + 1 OSS版: N/A Enterprise版: 部分的同期 ・任意のNodeに よるDenial of State攻撃により Validityが失われ る ・任意のNodeに よる無限ループを 含んだContract を実行するTXに よりLivenessが失 われる Corda NN Corda VN HLF Quorum 任意のNodeによ る無限ループを含 んだContractを 実行するTXによ りLivenessが失わ れる

17 © LayerX Inc. Corda 1回の状態遷移 で読み書きでき る状態データの 範囲 状態遷移ロジッ クの表現力 状態遷移ロジッ クの更新難易度 HLF Quorum 低 低 高 Cordaは1回の状態遷移で読み書きできる状態データの範囲がトランザクションの内容に 限定されるが、HLFとQuorumは全ての状態データに対して読み書きができる。 CordaとHLFの状態遷移ロジックの表現力は高く、更新難易度は低い。 Quorumの状態遷移ロジックの表現力は低く、更新難易度は高い。 4. 基本設計の比較 状態遷移ロジックの柔軟性 高 高 低 トランザクションの内容の み 全てのデータ 全てのデータ

18 © LayerX Inc. 公開資料・お問い合わせ 5

19 © LayerX Inc. 公開資料・お問い合わせ https://layerx.co.jp/publications/leaf_basic/ レポート全体をダウンロード お問い合わせ https://layerx.co.jp/ @LayerXcom で研究や最新ニュースを配信中！ 5. 公開情報・お問い合わせ

20 © LayerX Inc. ブロックチェーン技術をもとに、「新たな経済基盤」をつくりだす。 それは、信用や評価のあり方を変え、 業務や生産をはじめとした経済活動の摩擦を解消し、 この国の課題である生産性向上を実現する。 私たちは、そう信じて行動し続けます。 ブロックチェーンが実装された社会、 そこには、これまでの延⻑にはないまったく新しい可能性が広がっている。 LayerXは、デジタル社会への発展を後押しすることで、 経済史に新たな1ページを刻んでいきます。