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