Recomendados
Más contenido relacionado
Último
Último (10)
Destacado
Destacado (20)
20180410 blockchain tokyo-07
- 1. / 37 MAST / Taprootによるスマートコン トラクト DMM.comラボ スマートコントラクト事業部 加嵜長門 2018年4月10日 blockchain.tokyo#7
- 2. / 37 自己紹介 • 加嵜 長門（カサキ ナガト） • 2014年4月～ DMM.comラボ • Hadoop基盤構築・Sparkを用いたレコメンド開発 • 2018年1月～ DMM スマートコントラクト事業部 2
- 3. / 37 自己紹介 • 『詳解Apache Spark』技術評論社、2016年4月 • 『ビッグデータ分析・活用のためのSQLレシピ』マイナビ出版、2017年3月 • 『ブロックチェーンアプリケーション開発の教科書』マイナビ出版、2018年2月 3 https://www.amazon.co.jp/加嵜-長門/e/B01LZA6MUW/
- 4. / 37 今日の発表予定 • MAST/Taprootによるスマートコントラクト 4 スマートコントラクトの課題 イーサリアムにおけるスマートコントラクト ビットコインにおけるスマートコントラクト P2SH, P2WSH MASTの解説 MASTのアイデア メリット、応用例 Taprootの解説 シュノア署名 / MuSig Taprootのアイデア Graftrootのアイデア
- 6. / 37 スマートコントラクトとは • 契約の自動執行 • 自動販売機 • 電子マネーのオートチャージ • etc. • ブロックチェーンにおけるスマートコントラクト • 電子化された資産を、自動的に移転する仕組み • 代表的なプラットフォームは「イーサリアム」 6
- 8. / 37 ビットコインにおけるスマートコントラクト • Rootstock • イーサリアム互換のスマートコントラクトを実行可能 • ビットコインのサイドチェーン上でEVMを実行する • Counterparty • イーサリアム互換のスマートコントラクトを実行可能 • ビットコインのメインチェーン上でEVMを実行する • P2SH（Pay to Script Hash） • スクリプトに対して支払いを行う • そのスクリプトの条件を満たした場合にコインを取り出せる • 限定的なスマートコントラクトを実現可能 8
- 9. / 37 ビットコインにおけるP2SH 9 P2SH アリス Bitcoin Script により記述 Redeem Script 送金 限定的な記述しかできない反面 セキュリティを担保しやすい IF ELSE ENDIF 条件1 条件2 ハッシュ化
- 10. / 37 P2SHの課題とP2WSH • Redeem Scriptのデータサイズ制限が厳しい • 520 bytes以下 • マルチシグを実装する場合でも、1-of-15程度の規模が限界 • P2WSH (Pay to Witness Script Hash) • Redeem Scriptを、SegWitのWitness領域に退避 • スクリプトのサイズ制限を拡張 • 10,000 bytesまでは記述可能 10
- 11. / 37 P2SHやP2WSHの課題 • スクリプトの複雑化に伴い、手数料が上がる • ブロックに載せるデータサイズが増加するため • スクリプトに関係するアドレスが全公開されてしまう • プライバシーの観点で懸念 11
- 12. / 37 MAST 12
- 13. / 37 MAST • MAST: Merkle Tree + AST（Abstract Syntax Trees） • 2016年4月にJohnson Lauが提案 • 複雑なスクリプトを記述しても、実行されるロジックはその極 一部であることが多い • 排他的な条件に分割したスクリプトのマークルルートに対して 支払いを行う 13
- 14. / 37 MASTのアイデア 14 MAST Root アリス 送金 条件1 条件2 条件3 条件4 ・・・ Merkle Tree ハッシュ値 IF ELSE ENDIF 条件1 条件2
- 15. / 37 MASTのメリット • スクリプトの条件が複雑になっても、実際に実行した条件のみ をブロックに取り込めば良い • ブロックに取り込むべきデータサイズを抑えることができる • ブロックに取り込まれなかったスクリプトを秘匿することがで きる 15
- 16. / 37 MASTの応用例 • 大規模マルチシグ • 1-of-1000などの、分母が膨大なマルチシグに応用可能 • ハニーポットなどに活用 16 100 BTC サーバ1 秘密鍵1 サーバ2 秘密鍵2 サーバ3 秘密鍵3 サーバ1000 秘密鍵 1000・・・ 1-of-1000マルチシグ ハニーポット
- 17. / 37 MASTの実装提案 • BIP-114系 • Johnson Lauによる提案 • SegWitを前提にMAST Scriptとして再提案 • https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017- September/014963.html • BIP-116系 • Mark Friedenbachによる提案 • 拡張用に準備されていたオペコード（OP_NOP）を使用 • 再帰呼び出し(tail-call)を可能とさせる • https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017- September/015028.html 17
- 18. / 37 MASTの課題 • MASTのトランザクション（Merkle Root）は、通常のトランザ クション（アドレス）よりデータサイズが大きくなる • 効率性と秘匿性のトレードオフ • 必要な場合にだけMASTを利用すると、そのトランザクションでMAST を使っていることは分かってしまう（秘匿性の低下） • すべてのトランザクションをMASTにしてしまうと、通常のトランザ クションと区別はつかなくなるが、データサイズが増える（効率性の 低下） 18
- 19. / 37 Taproot 19
- 20. / 37 Taproot • 2018年1月にGregory Maxwellが提案 • MASTにおける効率性と秘匿性のトレードオフを解消 20
- 21. / 37 Taprootの前に • シュノア署名 • RSAやECDSAなどの署名アルゴリズムのひとつ • 公開鍵の集約特性を持つ • MuSig • シュノア署名をベースにしたマルチシグの実装 21
- 22. / 37 シュノア署名を用いた集約鍵 22 アリス 秘密鍵A 秘密鍵A 秘密鍵B アリス ボブ 公開鍵A 公開鍵A 公開鍵B 集約鍵C フォーマットで区別がつかない
- 23. / 37 Taprootのアイデア 23 シュノア署名フォー マットの公開鍵 アリス 送金 集約鍵 公開鍵1 公開鍵2 公開鍵3 ・・・ 任意のScript マルチシグ 例外処理
- 24. / 37 Taprootのアイデア • MASTにおける条件を、 「シュノア署名ベースのマルチシグ or 例外処理スクリプト」 というフォーマットに統一する • Taprootのアドレスは、通常のトランザクションと区別できない （秘匿性の担保） • マルチシグの母数やスクリプトの複雑度によらずデータサイズ が一定（効率性の担保） 24
- 25. / 37 Taprootの課題 • 例外処理に単一のスクリプトしか指定できない • MASTと比較して記述の柔軟性は劣る 25
- 26. / 37 Graftroot • 2018年2月にGregory Maxwellが提案 • Taprootの効率性と秘匿性を保ちつつ、柔軟性を担保 26
- 27. / 37 Graftrootのアイデア 27 シュノア署名フォー マットの公開鍵 アリス 送金 集約鍵 公開鍵1 公開鍵2 公開鍵3 ・・・ 任意のScript 1 署名済みScript 任意のScript 2 ・ ・ ・ 集約鍵に対応する署名済み Scriptでアンロック可能とする 委譲可能 マルチシグ 例外処理
- 28. / 37 Graftroot ELI5 • アリスとボブは、共通の財産（100BTC）を 2-of-2のマルチシ グで管理したい 28 アリス ボブ 100 BTC https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/
- 29. / 37 Graftroot銀行 Graftroot ELI5 • アリスとボブは、それぞれの印鑑から共有印鑑を作成し、その 印鑑を使ってGraftroot銀行に100BTCを預ける 29 アリス ボブ 100 BTC アリスの印鑑 ボブの印鑑 アリスとボブの共有印鑑 https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/
- 30. / 37 Graftroot銀行 Graftroot ELI5 • アリスとボブは、2人の合意があれば、共有印鑑を使っていつ でも100BTCを引き出すことができる 30 アリス ボブ 100 BTC アリスとボブの共有印鑑 https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/
- 31. / 37 Graftroot ELI5 • ボブは、アリスが死亡してしまったときの保険として、共有印 鑑で捺印した契約書を保持しておく 31 アリス ボブ アリスの印鑑 ボブの印鑑 アリスとボブの共有印鑑 A＆B 捺印 保持 https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/
- 32. / 37 Graftroot ELI5 • 共有印鑑で捺印した契約書があれば、ボブは契約書に記された 条件（1年後以降、など）でボブの印鑑のみで100BTCを引き出 せる 32 ボブ ボブの印鑑 A＆B Graftroot銀行 100 BTC https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/
- 33. / 37 Graftroot ELI5 • アリスとボブは、2人とも死亡してしまったときの保険として、 共有印鑑で捺印した契約書を娘のキャロルに託しておく 33 アリス ボブ アリスの印鑑 ボブの印鑑 アリスとボブの共有印鑑 A＆B 捺印 キャロル 委譲 https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/
- 34. / 37 Graftroot ELI5 • アリスとボブは、共有印鑑があれば、いつでも新しい契約書を 作成して、100BTCを引き出す権利を誰かに委譲できる 34 アリス ボブ アリスの印鑑 ボブの印鑑 アリスとボブの共有印鑑 A＆B 捺印 キャロル 委譲 A＆B デイヴ 委譲 A＆B エレン 委譲
- 35. / 37 Graftrootのメリット • Graftrootのアドレスは、通常のトランザクションと区別できな い（秘匿性の担保） • 例外処理スクリプトをどれだけ増やしても、データサイズは一 定（効率性の担保） • 集約鍵による署名スクリプトをあとからいくらでも増やせるこ とで、自由に条件を記述できる（柔軟性の担保） 35
- 36. / 37 まとめ 36
- 37. / 37 まとめ • ビットコインにおけるスマートコントラクト • スクリプトに対する支払いを可能にすることで、ビットコインでも限 定的なスマートコントラクトを実現可能 37 アイデア 特徴 課題 導入面 P2SH / P2WSH 限定的なスマートコントラクト を実現可能 容量制限が厳しい 実装済 MAST 複雑なコントラクトを実現可能 効率性と秘匿性のト レードオフ 未実装 シュノア署名 / MuSig スケーラブルなマルチシグ スクリプトではない 未実装 Taproot 高効率性と秘匿性 柔軟性に劣る シュノア署名実 装後 Graftroot 効率性、秘匿性、柔軟性 まだアイデア段階