ブロックチェーンの Proof-of-workの計算資源を利用して最適化問題の解探索を行うプロトコル

ブロックチェーンの Proof-of-workの計算資源を利用して最適化問題の解探索を行うプロトコル
ブロックチェーンのproof-of-workの計算資源を利用して最適化問題の解探索を行うプロトコル柴田直樹 1
背景 • ビットコインは非常にロバストな暗号通貨 – 完全分散のシステムであり，外部の計算機に依存せず，善良なノードが十分多く参加し続ける限り動作する ← 単なるデータが金銭的価値を持つために必要 • Proof-of-work(PoW) と呼ばれる仕組みにより多数決を取り，正しい取引を保証 – PoW は非常にロバストに動作するが，計算資源および電力を浪費する – 2018年にブロックチェーンのために浪費された電力(少なくとも 2.55GW)は，アイルランド全体で消費された電力(3.1GW)に匹敵する • 電力が浪費される問題の解消のため代替プロトコルがいくつか提案されてきたが，依然としてPoWがよく用いられている – 同等のロバスト性の確保が難しい – 一部の代替プロトコルは完全分散でない 2
目的 • Proof-of-work を代替するプロトコルの提案 – Proof-of-search(PoS) • PoS により多数決を取りつつ最適化問題の解探索を行える – 最適化問題の解探索を行うバッチ処理システムとして利用可能 • 任意のユーザ(クライアント)が任意の問題のインスタンスを登録 • 解探索終了後見つかった近似解がブロックチェーンに登録される – 問題が登録されていない場合は PoW にフォールバック • Proof-of-work の良い性質を全て保存 – 完全分散であり，外部の組織や計算ノードに依存しない – なりすまし耐性 – 事前登録なしにいつでも参加可能 – マイニングノードが新たなブロックの追加に成功する確率はそのノードの CPU 資源の量に比例する 3
アウトライン • 背景・目的 • ビットコインと proof-of-work • 関連研究 • 提案手法 • まとめ 4
ユーザ視点から見たビットコイン • 電子財布 – ビットコインアドレスと秘密・公開鍵ペアを含むソフトウェア – 銀行の口座に似ている • 支払いを行うには – コインを受取人のアドレスに送るよう指示 – 受取人の物理的な身元を知る必要はない • 基本的には支払いのためのシステムだが，実際にはもっと複雑なこともできる – Ethereumにおけるスマートコントラクト等 • 全てのビットコインの取引は公開され，全履歴がネットワークに保存される – 全てのユーザの口座の残高と取引は誰でも見ることができる – これにより，コインの所有者を確認することができ，コインの二重使用等を防止する 5
マイナーの視点から見たビットコイン • ビットコインを決済システムとして利用するユーザとは別に，ネットワークを維持するユーザ群（マイナー）がいる • マイナーはシステムに計算能力を提供することにより，新たに発行されるコインを見返りに受け取る – 計算能力を提供するためのコスト vs. コインの価値 • マイナーは P2P ネットワークを構成 – ネットワークは固定されたトポロジを持たず，各ノードはいくつかのランダムなノードと接続している – ユーザが支払いを行うためにはこのネットワークにメッセージを送信 6
ビットコイン • 実現する上でのポイント – コインの二重使用をどうやって防ぐか？ – 完全分散のシステムにおいて，悪意のあるノードが混じってもきちんと動くようにするには？ → 多数決で何が正しいか決める – ネットワークにおいては多数のIPアドレスを確保するのが容易 • IP アドレスに対して投票権を与えるのであれば，IP アドレスをたくさん確保できるユーザがシステムを乗っ取ってしまう → 計算量に対して投票権を与える • ほとんどの計算量が善良なノードによって供給される場合に正しく動作する多数決の仕組み 7 S. Nakamoto, “Bitcoin: A peer-to-peer electronic system,” 2008. http://bitcoin.org/bitcoin.pdf
タイムスタンプサーバ(ブロックチェーン) • 全ての取引をタイムスタンプサーバに記録 – 簡単のため，参加ノード全てが全ての情報を保持すると考える • 過去の全取引情報を任意のノードが参照できるようにする – 随時，記録された取引情報の正しさをチェックする • タイムスタンプの各ブロックは，過去のタイムスタンプのハッシュ値を含むことで，一本のリストを構成する – 項目が追加されることで，過去の情報の信頼性が向上する 8 ハッシュハッシュブロックブロック項目項目項目項目
Proof-of-Work • Proof-of-work はブロック全体のハッシュ値の先頭の決められた数のビットがゼロになるようなナンスと呼ばれる値を探す – ハッシュ値の性質より，このようなナンスを見つけるには様々なナンスに対してハッシュ値を計算し，偶然見つける必要がある • このようなナンスを示すことにより，ゼロの数に応じた計算を行ったことの確率的な証明となる 9 ハッシュ関数( ) = 0x00000f8a7…. この値をハッシュ値の先頭の指定された数のビットがゼロになるように定めるブロック前ブロックのハッシュ取引情報取引情報
多数決を取る方法 • ブロックのハッシュ値が決められた数のゼロで始まるようなナンスを全てのマイナーがこぞって探す – 見つけたマイナーはそのナンスを含むブロックをブロードキャスト – 各マイナーは最も長く，履歴の内容が正しい(ここで二重使用をチェック)チェーンに対しブロックの追加を試みる → 計算能力のほとんどが善良なノードにより供給されるなら，正しいチェーンが最も速く伸びる – 多数決として機能 – 計算能力の低い攻撃者が過去のブロックを改変しようとする場合 • 改変しようとするブロックとそれ以降のブロックの proof-of-work を全てやり直す必要がある • そのようなチェーンが最も長くなる確率は低い 10 ブロック前ブロックのハッシュブロック前ブロックのハッシュ取引情報取引情報取引情報取引情報
ネットワークの維持 • 新しいブロックの追加に成功したマイナーに新たなコインを授与 – 新しいコインを発行する仕組みとしても機能する – マイナーはコイン目当てにネットワークを維持する • 基本的にはマイナーにより全ての取引の検証・ネットワークの維持がなされる • ブロックが追加されるのにかかる時間をブロック時間と呼ぶ – ハッシュ値のゼロビットの数は，ブロック時間の期待値が10分になるように自動的に調整される 12
アウトライン • 背景・目的 • ビットコインと Proof-of-work • 関連研究 – Proof-of-stake, proof-of-activity – Proof-of-useful-work, Primecoin, Gridcoin – Permacoin, proof-of-space • 提案手法 • まとめ 13
Proof-of-stake • 基本的には所持する通貨の量によってブロックを追加するノードを選ぶ – 金持ちのノードほど頻繁にブロックを追加することができ，多くのコインを得る → 預金に対して利子がつくようなもの • 金持ちのノードが実質的にネットワークをコントロールする – 金持ちのノードを信頼する必要がある • CPU資源の浪費の問題はない • Proof-of-activityは，PoWとProof-of-stakeの組み合わせ – ネットワークをコントロールするためにはCPU資源と所持する通貨の両方が必要となるため，Proof-of-stakeよりロバスト – (純粋な)PoW よりもCPU資源の浪費は穏やか 14
多数決のための CPU 資源を意味のある用途に使うためのプロトコル • Proof-of-useful-work ：多数決のためのCPU資源を Orthogonal Vectors Problemsを解くために利用できる – 問題のクラスが狭すぎる • Primecoin ：新たな素数を探すことで多数決をとる – 素数を探すことに対する社会的需要があまりない • Gridcoin：マイナーがBOINCで行った計算量に対しインセンティブを授与する – CPU資源は意味のある用途に利用される – 暗号通貨全体がBOINCシステムに依存する – BOINCシステムがダウンすると機能しなくなる – 完全分散ではなく，ロバストとはいえない 15
多数決のためにストレージを利用するプロトコル • データを格納していることを持って多数決の票を与えられる – PoW に比べて電力の浪費ははるかに低くてすむ • Permacoin – マイニングノードを分散データストレージとして利用できる – あまり効率が良くない • 任意のノードの電源断に対処するための冗長性が必要 • Proof-of-space – マイナーは大きなデータをストレージに格納しておく – データが格納されていることを暗号学的に証明する • 必要な通信量と計算量が小さくてすむプロトコル – 弱点：同一のストレージ領域を利用して複数のチェーンをマイニングしたり，わずかに異なる複数のブロックの中で都合の良いものを選んで追加できてしまう • 実際にこのような攻撃を受けている 16
アウトライン • 背景・目的 • ビットコインと Proof-of-work • 関連研究 • 提案手法 • まとめ 17
目的 • Proof-of-work を代替するプロトコルの提案 – Proof-of-search(PoS) • PoS により多数決を取りつつ最適化問題の解探索を行える – 最適化問題の解探索を行うバッチ処理システムとして利用可能 – 任意のユーザ(クライアント)が任意の問題のインスタンスを登録 – 計算終了後，見つかった近似解がブロックチェーンに登録される • Proof-of-work の良い性質を全て保存 – 完全分散であり，外部の組織や計算ノードに依存しない – なりすまし耐性 – 事前登録なしにいつでも参加可能 – マイニングノードが新たなブロックの追加に成功する確率はそのノードの CPU 資源の量に比例する 18
キーアイデア • 多数決を取りつつ最適化問題の解探索を行えるようにしたい – ハッシュ関数を計算する代わりに解候補の評価値を計算する • 遺伝アルゴリズムなどでは，多数の解候補を評価することにより解探索が進行する → ブロック追加のために多数の解候補が評価されるようにしたい • 最適化問題の解候補とその評価値の連結をナンスとする – PoWと同様に、ブロックのハッシュ値が決められた数のゼロビットで始まるようなナンスを見つけることでブロックを追加する – ナンスを生成するために新たな解候補を評価する必要がある • ブロックを追加できるナンスを探すために解候補を評価 – 解候補を評価するためのCPU資源を解探索に利用 – 評価する解候補の数が増えるほど勝率が上がる → 勝率が計算量におおむね比例 19
不正の防止 • 一部のノードが良い解を知っているケース – ジョブ登録前にあらかじめ計算しておく – もし新たに発行されるコインを最も良い解を見つけたマイナーに授与するなら問題になる • 解決法：良い解を見つける報奨金をクライアントが支払う – 共謀したマイナーが良い解を見つけても，その報奨金はクライアントが支払う – 実質的にクライアントからマイナーに送金しているのと同じであり，メリットがない • 新しいブロックを追加する報奨金と良い解を見つける報奨金を独立させる – ブロックのハッシュ値が決められた数のゼロビットで始まるようなナンスを見つけることでブロックを追加 → PoWと同様にコインを授与 • この際には解の評価値は見ず，ハッシュ値のゼロビットの数だけで判断 – 最も良い解を見つけたマイナーにはクライアントが報奨金を支払う20
クライアントが実装した探索アルゴリズムをマイナーが使うようにする • 探索アルゴリズムをバイトコードなどで提出する – エバリュエータ：最適化問題の解候補の評価値を決定的に計算するプログラム，問題のインスタンスを含む – サーチャ：任意の解探索アルゴリズム(例：遺伝アルゴリズム)の実装，エバリュエータを内部的に呼び出す – ジョブ：解探索に必要なデータ全て．サーチャ，エバリュエータ，探索料金を含む • 例えば，あるクライアントが巡回セールスマン問題の解探索をリクエストする場合 – このクライアントがそのためのエバリュエータ，サーチャを実装 • エバリュエータの入力は都市の巡回順，出力は経路長 • ナンスは都市の巡回順と経路長の連結 – ナンスの生成のためにはエバリュエータを実行する必要 • サーチャとして，任意の探索アルゴリズムを実装する 21
クライアントの視点から見た具体的手順 • あるユーザがある問題のインスタンスを最適化してほしい – このユーザは，このインスタンスのエバリュエータとサーチャを実装 – 解探索のために支払う料金を決める – 上記3点を組み合わせてジョブを作り，ブロックチェーンに登録 • ジョブはいずれ実行される – ジョブの実行料金は自動的に引き落とされる – マイナーが使用するCPU資源の期待値は料金に依存 – 見つかった解はブロックチェーンに登録される • ユーザは，ブロックチェーンに登録された解を受け取る 22
マイナーの視点から見た具体的手順 • ジョブからサーチャとエバリュエータを抽出し，サーチャを実行する – サーチャは実行中に多数の解候補を生成し，エバリュエータを呼び出すことにより評価する – マイナーは最も評価値の良い解候補を保存しておく – 評価時にナンスを生成，ブロックのハッシュ値を計算 • もしこのハッシュ値が決められた数のゼロビットで始まるなら，ブロックをブロードキャスト • 新しいブロックが追加されるまでブロック時間が続く • ブロック時間終了後，各マイナーは最も評価値の良い解候補をチェーンに登録 23
料金と見つかった解の受け渡し • クライアントが支払った料金が確実に引き落とされるように → ジョブ登録直後に料金をクライアントの口座から引き落とし • 見つけた解を別のノードに盗まれることがないように – 単純に解をブロードキャストすると見つけた解を盗まれてしまう – ブロック時間 n に解探索が行われるとする – ブロック時間 n + 1 に見つけた解とノードIDの連結をチェーンに登録 – ブロック時間 n + 2 に解そのものをチェーンに登録 – クライアントはチェーンに登録された解を受け取ることができる • 最も良い解を見つけたノードに料金が支払われるように – チェーンに登録された内容から誰に料金を支払うか判定可能 – 最も良い解を見つけたノードの口座に料金が支払われたチェーンを正しいチェーンとしてマイナーが受理する 24
複数ジョブの同時実行 (1/2) • ジョブの実行料金を手頃にしたい – 支払う額に応じて解探索に費やされるCPU時間を可変したい • ブロックの追加に成功する可能性がCPU時間に比例するようにしたい • ブロック時間をクライアントが支払う額に応じて可変すると – ブロック時間が短くなると，ブロックチェーンがフォークする頻度が高くなるという問題がある → ブロック時間を変えずにジョブのCPU時間の期待値を可変提案手法では，ブロックの間にミニブロックを設ける • これにより，下記の追加特典がある – フォークの頻度が減る – ブロック時間の分散が減る 25
複数ジョブの同時実行 (2/2) • ブロックの間にミニブロックを設ける • 各ミニブロックが一つのジョブに対応する • ミニブロック毎に指定された個数のゼロビットで始まるような有効なナンスを探す – ジョブの料金に応じてゼロビットの数をミニブロック毎に変える • マイナーはどのミニブロックから探索しても良い • 全ミニブロックが追加されると，次のブロック時間に移行 26 ブロックハッシュ値ハッシュ値次のブロックハッシュ値ハッシュ値ハッシュ値値値 … ハッシュ値値値 … ナンスミニブロック 1 ハッシュ値ノードID 1 ナンスミニブロック N ハッシュ値ノードID N
ジョブの実行環境 • エバリュエータとサーチャの実行環境は下記の性質を満たす必要がある • プログラムが決定的に動作 • プログラムが適切に実装されてない場合に備える – 信頼できないプログラムを安全に実行 – プログラムが停止しない場合備え，決められたステップ数の実行後にプログラムを停止する機構 – プログラムがクラッシュした場合に決められた値を返す • 上記の機能を備えるインタプリタを実装するのは比較的容易 – 決定的な動作は非決定的に動作する API を提供しないことで実現可能 27
まとめ • ブロックチェーンにおいて最適化問題の近似解を探索することで多数決を取るプロトコルを提案 – ブロックチェーンの維持のために浪費されている莫大な電力を最適化問題の近似解を探索に利用できる • Bitcoin の PoW に似た方式とすることにより，完全分散で頑健なプロトコルを実現 – 外部組織に依存しないという点で Gridcoin より優れている 28

Check these out next

ブロックチェーンの Proof-of-workの計算資源を利用して最適化問題の解探索を行うプロトコル

Recommended

More Related Content

More from Naoki Shibata(20)

Recently uploaded(20)

ブロックチェーンの Proof-of-workの計算資源を利用して最適化問題の解探索を行うプロトコル