2018/11/19 blockchain.tokyo #14 https://blockchain-tokyo.connpass.com/event/105918/

1. 51% 攻撃の原理とシミュレーション
竹井 悠人 (@yutopio_ja)
ソフトウェア エンジニア
株式会社 bitFlyer
2018/11/19 blockchain.tokyo #14
https://blockchain-tokyo.connpass.com/event/105918/

2. 免責
このトークは、情報提供のみを目的として行われており、正確性・最新性についての保
障は一切ありません。内容は、会社の見解ではありません。この情報を元にして生じた
不利益について、当社およびスピーカは一切の責任を負いません。
bitFlyer 上での取引についての詳細は、当社カスタマ サポートへお問い合わせくださ
い。

3. 自己紹介
竹井 悠人
Yuto Takei C# 大好き一筋 17 年 / 筋トレ勢
いまさらポケモンにはまってます
大学生になりました
投げ銭いつでもウェルカム
Software Engineer / CISO

4. bitFlyer のブロックチェーン
C# でスクラッチから設計した
ブロックチェーンを研究・開発
|ω・`） ﾁﾗｯ
エンジニア募集してるってよ

5. 目次
1. ブロックチェーンと合意形成の関係
2. MinChain の紹介
3. 51% 攻撃のデモ

6. ブロックチェーンと合意形成の関係

7. ブロックチェーンとは
なにそれ美味しいの？
● 任意のデータの入れ物 (e.g. トランザクション) を作って、そのダイジェストを何かし
ら (e.g. ブロック) のハッシュ チェーンで繋いだデータ構造
何に向いているの？
● 透明性と完全性の要求が極めて高いケース
● 過去からのすべてのデータ (改訂や変更履歴など) を残したいケース

8. ハッシュ
ブロックチェーン概略図
Block
100002
Block
100001
前のブロック
000000000003ba27aa200b1c…
(ブロック 100000 のダイジェスト)
日時
2010/12/29 12:06:44
トランザクション ID
● bb28a1a5b3a02e76…
● fbde5d03b027d2b9…
● 8131ffb0a2c945ec…
● …
前のブロック
00000000000080b66c911bd5…
(ブロック 100001 のダイジェスト)
日時
2010/12/29 12:17:31
トランザクション ID
● ef1d870d24c85b89…
● f9fc751cb7dc3724…
● db60fb93d736894e…
● …
中身
参考: https://chainflyer.bitflyer.jp/v1/block/height/100001

9. ブロックチェーンに求められるもの
非機能要件
● 参加者が一定のルールに従って書き込むことができる
● 書き込まれたデータが、世界中のノードで読むことができる
● 正常な書き込み要求は必ずいつか処理される
● ルールに反するデータの書き込み要求は却下される
● ルールに従わない (正常な書き込みに応じない、不正な書き込みを受理する) ノー
ドが一定数いても動作する
非機能要件のようだが、本質的には違うと考えられるもの
● 改竄されたら検知できること (上記の当然の帰結)
● データの履歴が残ること (副次的に生まれた機能)

10. ブロックチェーンとは (再定義)
ブロックチェーンとは
1. 前スライドの要件を満たすデータ構造であり、
2. 1. を運用するシステムであり、
3. 2. を実現する技術の総称
である。
ここから、ブロックチェーンは
● 分散システムの一種である (i.e. 複数のサブシステムが協調する)
● 分散データベースの一種である (i.e. データ同期する)
といえる

11. 単純なブロックチェーンの設計
状
態
0
状
態
1
状
態
2
トランザクション 1
トランザクション 2
トランザクション 3
ブロックに
集約
参
加
者
間
で
合
意
形
成
…

12. 合意形成とは
目的は、分散システムの耐障害性確保のため、複数ノードに同一動作させること
ステートマシン レプリケーション問題 (複数の状態遷移機械が
同一に動作することを保証するため、入力するアルファベット
を同期させる) に帰着可
ノード 1
命令
A
ノード 2
命令
B
命令
A
ノード 1
ノード 2
命令
B

13. そもそも…
● ブロックチェーンが誕生するはるか昔から存在 (1980 年代)
● 分散ファイル システムなどで頻繁に利用 (有名なのは Spanner)
単純なやり方は、投票
合意形成とは
ラーメン
ノード A
ノード D ノード C
ノード B
ラーメン
ラーメン
次郎
ラーメン

14. 投票だと、合意形成したあとに票の水増しをされたら意味がなくなる
Sybil 攻撃
ラーメン
ノード A
ノード D ノード C
ノード B
ラーメン
ラーメン
次郎
ラーメン
ノード
次郎
ノード
次郎
ノード
次郎
次郎
次郎
ノード
次郎
次郎 ノード
ノード
ノード
ノード
ノード
次郎
次郎
次郎
次郎
次郎
次郎
次郎
次郎
次郎

15. 誰を (合意形成の) 参加者とするかの違いで次に分類できる
● パブリック型
常に、不特定多数の人が、新たに参加したり、離脱したりできる
● それ以外 (プライベート型 / コンソーシアム型 etc.)
合意形成をはじめる段階で、参加者が特定されている
とはいえ、パブリック ブロックチェーンを閉じたネットワークに構築したり、
ブロックチェーン外の認証機構をつけたりすることで、「プライベート
ブロックチェーン」として運用することもしばしば ...
非機能要件のひとつ
● 参加者が一定のルールに従って書き込むことができる
の参加者って誰？
参加者の定義

16. 合意形成に求める性質
● 安全性 (Safety)
ある合意があったら、健全な全ノードでその合意が有効で、唯一である
● 活性 (Liveness)
合意形成を行おうとする場合、いずれ合意形成が完了する
非機能要件のひとつ
● 参加者が一定のルールに従って書き込むことができる
では、合意形成のルールに従わないノードがいた場合には？

17. ビザンチン耐性とは？
ビザンチン将軍問題は、東ローマ帝国（ビザンチン帝国）の首都コンスタンティノープルを攻略するオスマン帝国の将軍たちがそれぞ
れ軍団を率いて、ひとつの都市（コンスタンティノープル）を包囲している状況で発生する。将軍たちは、都市攻撃計画について合意
したいと考えている。最も単純な形では、将軍たちは、攻撃するか撤退するかだけを合意決定する。一部の将軍たちは攻撃したいと
言うだろうし、他は撤退を望むかもしれない。重要な点は、将軍たちはひとつの結論で合意しなければならないということである。つ
まり、一部の将軍だけで攻撃を仕掛けても敗北することは明らかで、全員一致で攻撃か撤退かを決めなければならないのである。ま
た、将軍たちは、それぞれ離れた場所に各軍団を配置しており、メッセンジャーを相互に送ることで合意を目指す。
引用元: Wikipedia 「ビザンチン将軍問題」
分散システムで、一部ノードがプロトコルに従わない可能性を考慮し、システムとして安
全性かつ健全性を保った合意形成ができる状態 (ビザンチン耐性)
とはいえ全ノード数の 1/3 以上が従わない場合は理論的に不可能

18. ブロックチェーンの合意形成
基本的に、参加者の中に合意形成のプロトコルに反する挙動をする人を前提
(ビザンチン耐性をもつ合意形成アルゴリズムが必要)
なぜか...?
● そもそも改竄防止のためのハッシュ チェーン自体が極めてコストの高いデータ構造
● それに見合うほどの信頼が必要な環境では、参加者間の合意も極めて厳格に行
われる必要がある

19. だいたいこんな感じ…
パブリック型 それ以外 (プライベートなど)
参加者
いつでも誰でも参加できる
(事前に特定することができない )
合意形成の参加者が
特定されている
安全性
ない
(あとから覆る可能性がある )
ある
(参加者間で合意は唯一 )
代表的な
アルゴリズム
Proof of Work
Paxos, Raft, PBFT,
Proof of Authority

20. ブロック内に Nonce と呼ばれる自由領域を用意し、ハッシュ値を調整できるようにした上で、ブロック
のダイジェストは先頭に0 が一定数続かなければいけないというルールを課した。ネットワークの計
算力に応じて、この数を調整することにした。(正確には difficulty パラメータによってダイジェスト値の最大値を指定)
ブロック作成者 (マイナー) は、上記のルールを満たすNonce を探さなければいけない。代わりに、
報酬をもらうことができる
専用ハードウェアにより現在は全世界で 1 秒間に 600 京回 (6×1018
) のダイジェスト計算が
行われている。10 分に一度の確率にするには 36 垓回に 1 回だけ成功するように調整
しなければいけない。これは先頭に 0 が 18 個続くのと同じ難易度
Nonce
1001
1002
1003
1004
1005
ブロック ダイジェスト
5b280ff64934df39…
4b33b9d69b6c53f1…
9fc09514d74d5d78…
f181b5ef17bdeaf2…
000000063f0d8704…
Proof of Work のおさらい
前ブロック …
日時 2009/1/3 …
Nonce ?????
トランザクション ID
… OK
前ブロック …
日時 2009/1/3 …
Nonce 1005
トランザクション ID
…

21. それでも万が一チェーンが分岐するようなことがあった場合には、どちらのチェーンを主
とするか、というルールを決める
Proof of Work のおさらい
ブロックを作るのを著しく難しくしておけば、
ネットワーク内で十分安定的に浸透する
それでも万が一、同時にブロックができたら、
どちらを主とするか比較ルールを決めておく

22. 51% 攻撃
Proof of Work の仕組みを利用して、支払いをなかったことにしてしまう攻撃
● 最長チェーンと信じられているチェーン (メイン チェーン) 上に投資されてきた計算
資源を上回る計算資源で、別の分岐したチェーンを作ってしまう
● 別のチェーンがネットワークにブロードキャストされるとチェーン再構成 (reorg) が
発生して、元のメイン チェーンは無効になる
● 取引所にコインを送金し、法定通貨に換金して引き出したあと、reorg させてコイン
を手元に残しつつ、同価値の法定通貨を手に入れる

23. 攻撃者が隠れて、強いチェーンをマイニングし、それを急に放出するケース
最長の分岐が優先されるルールを使えば、世の中が信じる
「メイン チェーン」を上回るペースでチェーンを伸ばし、
それを一気に放出することで、チェーンの再構成を誘発できる
51% 攻撃

24. 51% 攻撃の実例など
● Bitcoin Gold
● MONA コイン
取引所では、コインの入金トランザクションが十分に安定したとみなすまで、取引を保留
扱いとして、攻撃が行われるのを防いでいる
攻撃にかかるコストを確認できる Web サイトもある
https://crypto51.app/

25. ブロックチェーンを走らせてみる

26. MinChain について
教育用ブロックチェーンとして Bitcoin を参考に作成したブロックチェーン
https://github.com/yutopio/MinChain
● 約 2,000 行程度の C# で実装
● MessagePack によるブロックやトランザクションのシリアライズ
● Proof of Work によるコンセンサス アルゴリズム
● 簡単なマイニング アルゴリズムの実装
● MIT License に基づく再利用・頒布可

27. MinChain のモジュール構成
Executor
Mining
KeyGenerator
Config
Genesis
ツール群
InventoryManagerConnectionManager
解釈前のブロック保持
Memory Pool 保持
InventoryMessage 処理
Executor ブロック通知
Listener 新規接続待ち受け
Peer 一覧を保持
特定ピアへの送信
ブロードキャスト
Message 受信コールバック
実行済みブロック保持
UTXO の追跡
未実行ブロック一覧保持
ブロック適用/ 取消
Runner
各モジュールの
初期化 / 終了
Program
エントリ ポイント
コマンド振り分け

28. 動がしてみる
ビルドするには
git clone https://github.com/yutopio/MinChain
cd MinChain/MinChain
dotnet restore
dotnet build (既定で bin/Debug/netcoreapp2.0 にビルドされる)
動作させるには
dotnet genkey > key.json
dotnet genesis key.json genesis.bin
dotnet config > config.json (このあと config.json の編集が必要)
dotnet MinCHain.dll run config.json

29. 鍵を生成する
ビルドしたバイナリがいるディレクトリに移動して実行
$ dotnet MinChain.dll genkey > key.json (自分のアドレス用の口座を作成する)
$ cat key.json
{
"pub": "WAAAAAEAAAAQAAAANAAAACAAAAAEj0MOwNeLA9b4gXYbURcyF5c8YPtZekJcliWafKduNy
AAAAACMFgRiBxSiu3wB3/g3biz9UN8zvNGI2n/HIg88EVn8A==",
"prv": "D4TuwVREhf5T3GTs4Y1psaUoHHKy3hb4gllunB2x5l8=",
"addr": "MDyDMxi1ynxe1206ANBRXWOjP7o/IeQHakRDilyYrtI="
}

30. Genesis ブロックを作る
$ dotnet MinChain.dll genesis key.json genesis.bin
Creating new genesis block.
{
"id": "00011702146098209132fa4990686f41f3e6b9859c607c1e5c93c0204ff9d8ec",
"prev": "0000000000000000000000000000000000000000000000000000000000000000",
"difficulty": 2E-05,
"nonce": 2538555750346862341,
"timestamp": "2017-03-10T09:20:20.2375851Z",
"root": "DS5gHGHSJh0f5qmxgk2PDuI6a7J4LZ7pfy3K6JorH8U=",
"height": 0,
"txs": [
{
"id": "e44e859fe93bf48652b2dfc2386d987e544940f768379779da631fcd7206ac66",
"timestamp": "2017-03-10T09:20:19.5205851Z",
"in": [],
"out": [
{
"to": "303c833318b5ca7c5ed76d3a00d0515d63a33fba3f21e4076a44438a5c98aed2",
"val": 1000000
}
... (略)
key.json 記載のアドレスに
マイニング報酬を送るような
原始ブロックを作成し
genesis.bin に保存する
マイニングするので
少し時間かかる

31. config を作成する
$ dotnet MinChain.dll config > config.json
$ cat config.json
{
"listen": "0.0.0.0:9333",
"peers": [
"127.0.0.1:9333"
],
"keypair": "<YOUR OWN KEYPAIR>.json",
"genesis": "<GENESIS BLOCK>.bin"
}
前のステップで生成した
鍵ペアファイル (key.json) と
原始ブロック (genesis.bin) とに
それぞれ、ファイル名を変える

32. 起動する
$ dotnet MinChain.dll run config.json

33. 51% 攻撃を観測してみる

34. 参考
日経ソフトウェア 7月号に今日の内容は載ってます
オンラインでもよめます
https://bizboard.nikkeibp.co.jp/kijiken/summary/20180524/NSW0258H_4066560a.html

35. まとめ
● ブロックチェーンは、分散データベースである
○ 合意形成アルゴリズムが必要
○ 参加者の定義: 不特定多数か否か、によってパブリック型かどうかが変わる
○ ビザンチン耐性を備えた合意形成を用いるのが一般的
● 51% 攻撃
○ Proof of Work で可能な攻撃
○ 攻撃者が長いチェーンを作成し、一気に放出するだけ
○ 成功すると、意図的に取引をなかったことにできてしまう
● MinChain
○ https://github.com/yutopio/MinChain
○ Bitcoin タイプのブロックチェーンの簡単なモデル
○ attack ブランチに、攻撃のシミュレーションが入っている