BCIC

Blockchain Innovation Center

IBM Research - Tokyo

分散台帳技術におけるインテグリティとプライバシー保護に関する考察
2018年2⽉7⽇
⽇本アイ・ビー・エム株式会社 東京基礎研究所

吉濱佐知⼦

Sachiko Yoshihama
IBM Research – Tokyo© 2018 IBM Corporation© 2018 IBM Corporation※本資料の内容は個⼈の⾒解であり、所属企業の⾒解を代表するものではありません。

分散台帳技術にまつわる疑問• 分散台帳技術は⾊々あるが、どうやって⽐較すればいいのか？
• パフォーマンス？ 安全性？

• 例えばパフォーマンスを⽐較する場合• 「秒間〜〜件の処理が可能」といっても、ノード数や処理の複雑さ、各種構成パラメーター、によって⼤きく異なってしまう• 条件を揃えるため、様々なユースケースにおける「ベンチマーク」を作成し、様々な基盤を同じ条件で⽐較するのが⼀般的。

• 分散台帳技術の安全性の意味は？
• 「安全」ってどういう意味？
• 「プライバシーが守れる」ってどういう意味？
© 2018 IBM Corporation

2

分散台帳技術の安全性の意味を定義するには• 分散台帳技術の種類を、基本機能の観点から整理する• 分散台帳技術を使う参加者の種類を定義する• 安全性に求められる性質を整理し、その意味を定義する• 具体的なユースケースにおける安全性の要件を考えてみる• 代表的な分散台帳技術の実装における、それぞれの要件への対応状況を考察してみる© 2018 IBM Corporation

3分散台帳技術の安全性の意味を定義するには• 分散台帳技術の種類を、基本機能の観点から整理する• 分散台帳技術を使う参加者の種類と役割を定義する• 安全性に求められる性質を整理し、その意味を定義する• 具体的なユースケースにおける安全性の要件を考えてみる• 代表的な分散台帳技術の実装における、それぞれの要件への対応状況を考察してみる© 2018 IBM Corporation

4分散台帳技術の種類を、基本機能の観点から整理する•参加者タイプ•データ構造•トランザクション処理⽅式•コンセンサス© 2018 IBM Corporation

5

参加形態：Public vs. Permissioned
Public Network
誰でもネットワークに参加可能•

政府により規制されない、転々流通可能な仮想通貨を、中央集権的管理主体なしに実現© 2018 IBM Corporation

Permissioned Network
参加許可制• 業界コンソーシアムなどのビジネスネットワー
クの中で、組織をまたがる業務に適⽤• ⾼いセキュリティや信頼性への要件• 分散DB・コンピューティングの技術を取り⼊れ、業務システムとして受け⼊れやすい形に変化。 6

データ構造ブロックステート

トランザクションの履歴を記録。
暗号的ハッシュ関数により、過去のトランザクション履歴の改竄を困難とする構造。

Markel Hash Root

ブロック b(t)バージョン番号

ブロック b(t+1)
バージョン番号直前のブロックのハッシュ値

直前のブロックのハッシュ値

このブロックで承認するトランザクションのハッシュ値

このブロックで承認するトランザクションのハッシュ値

タイムスタンプ

タイムスタンプ

難易度（ターゲットの値）

難易度（ターゲットの値）

nonce

nonce

トランザクション数

トランザクション数

トランザクション0 (報酬)

トランザクション0 (報酬)

トランザクション1

トランザクション1::

トランザクションnt:

ステート(分散DB):

トランザクションnt+1

データ例： 取引記録
© 2018 IBM Corporation

トランザクションを実⾏した結果の最新状態を記録する。

データ例： 口座残高+ 任意の複雑な構造のデータ

7

トランザクション処理⽅式
UTXO(Unspent Transaction Output)

スマート・コントラクト

スマート・コントラクト• 任意のアプリケーションロジックを実⾏• ビジネス・プロセスやルールを、参加者間で共有• 複雑な処理を実装可能
スマート・コントラクト

ステート• アプリ・ロジック• ビジネスプロセス• ルール* source: Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System© 2018 IBM Corporation

8

コンセンサス⽅式
Proof-of-Work (PoW)

分散コンセンサス形成アルゴリズム

計算競争の勝者がブロックを追加する• メッセージ交換により合意形成を⾏とともに報酬を受ける
う、分散コンセンサス形アルゴリズ→ 計算資源量等に応じて確率的に勝⽅式
ム者が決まる。
(e.g., Paxos, VSR, Raft, PBFT, etc.)
亜種: PoI, PoS…
•⻑所 •スケーラビリティ

••
短所
•
•

安全性 (PoWにおける51%攻撃)
フォーク（分岐）ファイナリティ⽋如
電⼒使⽤量→コスト⾼対応ネットワーク© 2018 IBM Corporation

•

•••
•

軽量・低消費電⼒
フォークしないファイナリティを保証
⾼いパフォーマンスを実現しやすい•

ノード数が増えるとパフォーマンスが落ちやすい

Public Network で匿名の不特定多数•の参加者間で使⽤可能

Permissioned Network が前提
9

分散台帳技術の安全性の意味を定義するには• 分散台帳技術の種類を、基本機能の観点から整理する• 分散台帳技術を使う参加者の種類と役割を定義する• 安全性に求められる性質を整理し、その意味を定義する• 具体的なユースケースにおける安全性の要件を考えてみる• 代表的な分散台帳技術の実装における、それぞれの要件への対応状況を考察してみる© 2018 IBM Corporation

10分散台帳技術ネットワークのモデル
取引当事者

第三者
ノード
第三者
ノード

••
•

N個のノードが参加 {n1, n2,.. nN}
最⼤ f 個のノードがビザンチン障害
各取引において、取引当事者（カウンターパーティ）がいる。

••

i番⽬のノードの持つ台帳
dlti = { h(tx1), h(tx2), … h(txm)},{ tx1, tx2, … txm }•••各ノードは:

ü トランザクション内容の正当性をチェックするには txj を持つ必要がある
ü トランザクションの改竄を検知するだけならh(txj) を持っていればよい

攻撃者ノード（ビザンチン障害ノード）

取引当事者© 2018 IBM Corporation

txj : j番⽬のトランザクションh(txj) : トランザクションのハッシュ値

第三者
ノード11

分散台帳技術の安全性の意味を定義するには• 分散台帳技術の種類を、基本機能の観点から整理する• 分散台帳技術を使う参加者の種類と役割を定義する• 安全性に求められる性質を整理し、その意味を定義する• 具体的なユースケースにおける安全性の要件を考えてみる• 代表的な分散台帳技術の実装における、それぞれの要件への対応状況を考察してみる© 2018 IBM Corporation12安全性: 分散コンセンサス形成に求められる性質• 分散コンセンサス形成アルゴリズムは、分散システムの同期をとるための技術で、数⼗年来研究されている• ⾮同期型のメッセージ通信を前提とする（eventual-synchrony network model ）• メッセージがネットワーク内に発信 (broadcast) された後，コンセンサスを経て⼀定時間内に健全なノードに配信 (deliver) され、ノード間でメッセージの順序が保証される
安全＝アトミック・ブロードキャスト の性質を満たす *1• 有効性 (Validity):– 健全なノード p がメッセージ m を発信した場合，そのメッセージ m はいずれそのノード p 上に配信される．

• 合意 (Agreement)：– ある健全なノードにメッセージmが配信される場合，そのメッセージは全ての健全なノードに配信される．

• 完全性 (Integrity)：– 健全なノードは各メッセージを最⼤１回しか配信しない．

• 全順序 (Total Order) :– 任意の2 つの健全なノードの間で，常に配信されたメッセージの順序が同⼀となる．

© 2018 IBM Corporation*1: C. Cachin and M. Vukolić, Blockchain Consensus Protocols in the Wild, 2017.

13安全性: セキュリティ
分散台帳技術では、従来の分散システムよりも、セキュリティに対する要件が重要•

攻撃者の存在する環境で、利益相反する複数の主体が取引を行う

第三者
ノード

取引当事者
第三者
ノード

取引当事者
© 2018 IBM Corporation

攻撃者ノード（ビザンチン障害ノード）

第三者
ノード

インテグリティ要件[I1]トランザクション内容の正当性[I2] 改竄が検知できる[I3] ファイナリティ
プライバシー/秘匿性要件[C1]第三者に対する匿名性[C2] 取引当事者同⼠の匿名[C3] 第三者に対するトランザクション内容の秘匿[C4] 第三者に対するトランザクション存在の秘匿[C5] 第三者に対するステートの秘匿

14

分散台帳技術の安全性の意味を定義するには• 分散台帳技術の種類を、基本機能の観点から整理する• 分散台帳技術を使う参加者の種類と役割を定義する• 安全性に求められる性質を整理し、その意味を定義する• 具体的なユースケースにおける安全性の要件を考えてみる• 代表的な分散台帳技術の実装における、それぞれの要件への対応状況を考察してみる© 2018 IBM Corporation15

仮想通貨• 事例: Bitcoin, その他のコイン• ⼀般的な実装: UTXO + PoW（または亜種）によるパブリックネットワーク• 実装アプローチ– タイプ: Public or Permissioned– データ構造: ブロック and/or ステート
– トランザクション処理: UTXO or スマートコントラクト© 2018 IBM Corporation項⽬

要件[I1]トランザクション内容の正当性

必要[I2] 改竄が検知できる

必要[I3] ファイナリティ

ゆるい *[C1]第三者に対する匿名性

要[C2] 取引当事者同⼠の匿名性

要[C3]トランザクション内容の秘匿

ゆるい *[C4]トランザクションの存在の秘匿

ゆるい *[C5] ステートの秘匿ー* 本来は要件であると思われるが、UTXO実装が多いため、慣習的に満たさなくても許されている

16

証券ポストトレード処理•••

証券の取引が成⽴した後の、（売買注⽂の条件がマッチ）、証券と資⾦の決済
複雑なネッティング処理や、DVP (Delivery-versus-Payment) 決済が必要となる
実装アプローチ• タイプ: Permissioned （認可された⾦融機関に限定）• データ構造: ステート (and ブロック)• トランザクション処理: スマートコントラクト

ブロックチェーンによる⾦融市場インフラ

現在の⾦融市場インフラ

ブローカー

証券のマスターデータ管理
証券の決済（振替）
証券台帳

監督・監査

清算機関
Central Counter
Party (CCP)

監督機関
証券会社A

投資家

Central Securities
Depository (CSD)

資⾦決済

証券会社A

証券会社B

投資家

取引
照合
監査

証券会社B

証券会社C

投資家

投資家

証券
台帳

投資家

証券
台帳

証券会社C
© 2018 IBM Corporation

証券台帳

証券台帳

証券取引所

資⾦決済ネットワーク

ブローカー

投資家

17

証券ポストトレード処理• ある取引の決済が完了するためには、売り⼿の証券残⾼、買い⼿の資⾦残⾼が共に⼗分ある必要あり• 取引の内容は第三者ノードから秘匿する必要がある• 次に別のノードが取引をするときは、そのノードも証券残⾼・資⾦残⾼を参照できる必要がある
1

取引1売り⼿取引2買い⼿265

3
取引1買い⼿取引2売り⼿© 2018 IBM Corporation

第三者
ノード

4

攻撃者ノード（ビザンチン障害ノード）

第三者
ノード項⽬

要件

[I1]トランザクション内容の正当性必要（重要）[I2] 改竄が検知できる必要（重要）[I3] ファイナリティ

必要（重要）[C1]第三者に対する匿名性必要（重要）[C2] 取引当事者同⼠の匿名性

不要[C3]トランザクション内容の秘匿必要（重要）[C4]トランザクションの存在の秘匿

K-匿名性[C5] ステートの秘匿必要（重要）

18

⾦融契約
• 事例: デリバティブ契約や、デリバティブを証券化した⾦融商品• 例）株価連動社債 (ELN: Equity Linked Note)は，株式とオプション取引を組み合わせた⾦融商品• 実装アプローチ• タイプ: Permissioned （認可された⾦融機関に限定）• データ構造: ステート (and ブロック)• トランザクション処理: スマートコントラクト

発注
買い⼿が株式銘柄とstrikeprice指定
売り⼿合意
取引成⽴
決済⽇到来
未決済

© 2018 IBM Corporation

買い⼿が元⾦の割引価格を⽀払い
決済完了
評価⽇到来
株価 ≧
strike price?
株価がstrikeprice以上なら、買い⼿は元本を現⾦で受領

例: 株価連動社債のロジック

株価がstrikeprice未満なら、買い⼿は株式を受領

項⽬

要件[I1]トランザクション内容の正当性

必要 *1[I2] 改竄が検知できる

必要 *1[I3] ファイナリティ

必要 *1[C1]第三者に対する匿名性必要（重要）[C2] 取引当事者同⼠の匿名性

不要[C3]トランザクション内容の秘匿必要（重要）[C4]トランザクションの存在の秘匿

k-匿名性[C5] ステートの秘匿必要（重要）*1 ただし当事者同⼠が合意できれば問題ない
19

分散台帳技術の安全性の意味を定義するには• 分散台帳技術の種類を、基本機能の観点から整理する• 分散台帳技術を使う参加者の種類と役割を定義する• 安全性に求められる性質を整理し、その意味を定義する• 具体的なユースケースにおける安全性の要件を考えてみる• 代表的な分散台帳技術の実装における、それぞれの要件への対応状況を考察してみる© 2018 IBM Corporation

20代表的な分散台帳技術の⽐較
PublicSmartContract

UTXO© 2018 IBM Corporation

Permissioned

QuorumFabricR3 Corda21

まとめ• 分散台帳技術におけるインテグリティやプライバシーといったセキュリティ要件を定義し，既存の実装における要件の充⾜状況を考察• 仮想通貨など、分散台帳として従来型のユースケース• PoW実装を前提とした歴史上の理由から、ファイナリティに関する要件がゆるい• 匿名性以外の秘匿性要件も弱い• 証券ポストトレード処理や⾦融契約• ⾦融システムとして⾼額な決済が⾏われるため、法規制上強いプライバシー保護要件がある• 認可された⾦融機関だけ → Permissioned ブロックチェーンが必須• 複雑な状態遷移が発⽣するので、実装にはスマートコントラクトやステートが必要• プライバシーとインテグリティのトレードオフ• 「取引のプライバシーを守りつつ、残⾼は共有したい」というような相反する要求の難しさ• 分散台帳技術の⽐較• PoWやその亜種ではファイナリティが保証できない。
• パブリック型では匿名性は保証できるが、トランザクションの存在や中⾝は隠せない• Permissioned型はデータ暗号化や配布範囲を制限するなどプライバシー保護の⼯夫をしている⼀⽅、特別な役割のノードを持ち、これらのビザンチン障害を許容できない場合が多い© 2018 IBM Corporation22