Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Bitcoin スクリプトから理解するライトニングネットワーク

4,430 views

Published on

第1回 ブロックチェーンエンジニア勉強会 ( https://becj.connpass.com/event/74368/ ) での発表資料。

Published in: Technology
  • Be the first to comment

Bitcoin スクリプトから理解するライトニングネットワーク

  1. 1. Bitcoin スクリプトから 理解する ライトニングネットワーク そしてこの文脈で何故 segwit が重要か 発表者: Yuki INOUE
  2. 2. About Me ● Yuki INOUE ○ Twitter とかあんまやってません、、すいません。。 ● カウンティア株式会社所属 ○ ウォレットの研究開発とかやっています。 ● スタックオーバーフロー日本語版のモデレータとか。 ○ コミュニティドリブンな、プログラミングの QA サイト!
  3. 3. 目的 ● 背景: ライトニングネットワークについて、一通して理解できるような資料が見つから ない。 ● なのでこれを、いわば mastering lightning network 的な理解ができたらいいな、と 思った。 ● 目標は、ライトニングの技術的な設計について理解できるようになること。
  4. 4. 目次 1. Bitcoin のアドレス(スクリプト)についての説明 2. ライトニングの動作説明 3. ライトニングネットワークにおいて必要という文脈での segwit
  5. 5. 1. Bitcoin スクリプトについて そのためにまず bitcoin の確認
  6. 6. 確認: bitcoin とは ● アドレスからアドレスにコインを送る Transaction がある ● Transaction が P2P で共有される ○ Transaction を P2P に流すこと == Transaction を Broadcast する ● Transaction を束にして block に固める、 mining というオペレーションがある。 ○ block も P2P で共有されていく ● Lightening network ではこの Transaction に注目する。 では Transaction の中身とは
  7. 7. Transaction == TxInput の配列 + TxOutput の配列
  8. 8. TxIn と TxOut の役割 ● TxIn は送り元アドレス + 今作っている Tx の署名 に大体、相当 ● TxOut は送り先アドレス + 送金する量に相当 ● そしてアドレス ≒ 公開鍵
  9. 9. アドレス、署名、Transaction Alice Bob Charlie APub -> BPub: 10BTC Signed By APriv. Tx0 BPub -> CPub: 10BTC Signed by BPriv. Tx1
  10. 10. ところで ● アドレスからアドレスにコインを送る Transaction がある。 は正しくない。 ● 「過去の Transaction の出力」からアドレスにコインを送るのが Transaction ● 既に送金された「過去の Transaction の出力」から再度送金しようとする Tx は不 正として bitcoin protocol から弾かれる。
  11. 11. ところで: 正確にはアドレス -> アドレスではない APub -> BPub: 10BTC Signed By APriv. Input: * (TxZ, 0) Signed By APriv. Output: * 10BTC on BPub Input: * (TxA, 0) Signed By BPriv. Output: * 10BTC on CPub TxA Unspent Transaction Output (UTXO) TxB
  12. 12. (考察) 何故 UTXO か。 ● アドレスないし「アドレス残高」からの出金だと不都合がある。 ● 例: 入金・出金を繰り返した。 ○ 入金 -> 入金 -> 出金 -> 出金(残高不足でこれは失敗する ) がやりたかった。 ○ 出金 -> 出金 -> 入金 -> 入金 の順で到着した場合 ? ● 例: Transaction に手数料が足りずに mining されなかったので、手数料を増やし て作り直して再送したい。 ○ 受け取り側が悪意のある miner で、新しい方を confirm したのちに、古いほうをまた confirm してし まったら?
  13. 13. 再定義: TxIn と TxOut ● TxIn : 過去の TxOut の場所と、それに対応する署名 ● TxOut: 送り先アドレスと数量
  14. 14. Bitcoin Transaction: scriptSig, scriptPubKey: 署名と 公開鍵の仕組みの汎用化。 ● 語弊を恐れずに言えば: 「署名」と「公開鍵」の部分に好き勝手なスクリプトを入れて いいよ。 ● どう行われる: 「公開鍵」を「解除条件」、「署名」を解除のためのデータ。 ● それぞれ同一のスクリプトで記述して、つなげた時に、スクリプトが正常終了するこ と。 具体例から入ります
  15. 15. 具体例: (旧) アドレス方式: P2PK ● TxOut: scriptPubKey: “pubkey(定数)” OP_CHECKSIG ● TxIn: scriptSig: “sig(定数)” ● 「定数」とは、それをスタックに載っけてくれ、という指示詞 スタック スクリプト 次の action (空) <sig> <pubkey> OP_CHECKSIG <sig> を push <sig> <pubkey> OP_CHECKSIG <pubkey> を push <sig> <pubkey> OP_CHECKSIG スタックの top を公開鍵、 top-1 を 署名としてこの Tx を検証 true スクリプト終了時の top の値が非 0 ならば、 accept.
  16. 16. 具体例: 現行のアドレス方式: P2PKH ● scriptPubKey: OP_DUP OP_HASHSHA256 “pubkeyhash(定数)” OP_EQUALVERIFY OP_CHECKSIG ● scriptSig: “sig(定数)” “pubkey(定数)” スタック スクリプト Action 特記 (空) <sig> <pubkey> OP_DUP OP_SHA256 <pubkeyhash> OP_EQV OP_CHECKSIG Sig, pubkey を push。 Stack top の pubkey が dup されて sha256 される。 <sig> <pubkey> <pubkeyhash> <pubkeyhash> OP_EQV OP_CHECKSIG Pubkeyhash が push され == 比 較される <sig> <pubkey> OP_CHECKSIG 以降P2PK と同じ流れになる。 詳細は例えば: https://en.bitcoin.it/wiki/Script
  17. 17. スクリプト言語でできること ● スタック2つ (main, push/pop のみできる alt) ● 分岐処理 ● もろもろの暗号演算 ● 基本的四則演算、 push/pop/drop などの簡単な stack 操作 ● できないこと: loop 処理。 ● イメージ、 Excel の関数と同じぐらいのことができる。
  18. 18. 具体例: 2 of 2 マルチシグアドレスっぽいもの自作 # scriptSig 部分 sigA sigB # scriptPubKey 部分 pubB OP_CHECKSIG OP_NOTIF OP_RETURN OP_ENDIF pubA OP_CHECKSIG スタック スクリプト (空) <sigA> <sigB> <pubB> OP_CHECKSIG OP_NOTIF OP_RETURN OP_ENDIF <pubA> OP_CHECKSIG <sigA> <sigB> <pubB> OP_CHECKSIG OP_NOTIF OP_RETURN OP_ENDIF <pubA> OP_CHECKSIG <sigA> true OP_NOTIF OP_RETURN OP_ENDIF <pubA> OP_CHECKSIG <sigA> <pubA> OP_CHECKSIG TxIn TxOut POINT: if 文が使える。
  19. 19. OP_CHECKLOCKTIMEVERIFY + p2pkh ● scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG ● scriptSig: <sig> <pubkey>
  20. 20. スクリプトポイント ● ループを含まない、CHECKSIG や暗号ハッシュを組み合わせた任意の条件を記 述できる。 ● 特定の時刻ないしブロック高まで unlock できないアドレスを作れる
  21. 21. 2. Lightning Network
  22. 22. Lightning Network 概要 ● Block を経由しないで Tx をやりとりしていこうとするオフチェーン技術 ● 基本は、A さんと B さんの双方向 payment channel. ● 双方向 payment channel をつなげてネットワークにしたもの。
  23. 23. 2.1 双方向 payment channel
  24. 24. 注目点1: 誰が broadcast できるかゲーム木 UTXO0 Tx1a Out: Bob Alice can BroadCast Bob can BroadCast On Block Not On Block (Yet) Out: Special1 Tx1b Out: Alice Out: Special2 Tx2a Out: Bob Bob can BroadCast
  25. 25. 注目点2: 署名検証のロジック (OP_CHECKSIG) Transaction TxIn1 TxOut1 TxOut2 Txid index Script Sig1 TxIn2 Txid index Script Sig2 TxIn1 TxOut1 TxOut2 Txid index Script PK1 TxIn2 Txid index Script Sig1 Script PK1 CHECKSIG
  26. 26. 注目点2: TxIn は個別に署名していくことができる。 On Block Not On Block (Yet) Tx: OnBlock TxIn:sig0 Out(5): Alice TxIn:sig1 Tx: WIP TxIn: AliceSig Out(10): KevinTxIn: _______Tx: OnBlock TxIn:sigA Out(5): Bob TxIn:sigB
  27. 27. 双方向 payment channel 概要 ● チェーンに書き込むことなく、書き込まれない想定の Tx のみをやりとりして支払い を実現する。 ● お互いに multisig アドレスに deposit (channel を開くのはブロックチェーン上に書 き込む必要がある) ● 払い戻しの Tx をお互いに保持しておく。 ● Alice と Bob に支払ったら、チェーンに書きこむのではなく、払い戻し Tx を更新す る。 ● 払い戻し Tx を更新する際に、古い Tx を無効化するような Tx も発行しておく。
  28. 28. チャンネルが満たすべき性質 ● お互いが、今持っているべきコインを、相手が何をしようとも(最終的には)受け取れ る ● ゲーム木的に、相手が一方的に得するようなことがないようにする ● 支払いで Tx 更新を行う際には、支払い前か支払い後のどちらか一方のみが有効 になるようにする
  29. 29. 実現手段 ● Timelock 付きの脱出経路を A, B どちらも常に実行できるようにする。 ○ Abort できる。 ● 破棄したい Tx は、一時秘密鍵を相手に渡すことでゲーム理論的に自分・相手がそ れを実行しなくなる。
  30. 30. 実演: Alice と Bob
  31. 31. 事前準備: それぞれ一時的なアドレスを生成する。 ● 普通の、アドレスにひもづく秘密鍵 <-> 公開鍵のペアを、生成する。 ● それら一時的アドレスは、相手に共有しておく。 ● Alice: AliceTmp1, AliceTmp2, … ● Bob: BobTmp1, BobTmp2, …
  32. 32. まず: チャンネルをオープンする
  33. 33. はじめに: Alice が Deposit Tx 用意 Tx0: not broadcasted TxIn: __ Out(10): AlicePub and BobPubTxIn: __ Nobody can Broadcast TxOut(5): AlicePub TxOut(5): BobPub
  34. 34. Tx1Bob: {5, 5} TxIn: AliceSig, missing BobSig Out(5): AlicePub Out(5): {Timelock to BobPub} Or {AlicePub and BobTmp1Pub} Alice が Bob が実行できる払い戻し Tx 用意・共有 Tx0: not broadcasted TxIn: Alice(5) + __ Out(10): AlicePub and BobPubTxIn: Bob(5) + __ Nobody can Broadcast Bob can Broadcast
  35. 35. Tx1Alice: {5, 5} TxIn: BobSig, missing AliceSig Out(5): BobPub Out(5): {Timelock to AlicePub} or {BobPub and AliceTmpPub} Bob が、 Alice が実行できる払い戻し Tx 用意・共有 Tx0: not broadcasted TxIn: Alice(5) + __ Out(10): AlicePub and BobPubTxIn: Bob(5) + __ Nobody can Broadcast Bob can Broadcast Tx1Bob: {5, 5} Alice can Broadcast
  36. 36. Alice が Deposix Tx に署名 Tx0: not broadcasted TxIn: Alice(5) + sig Out(10): AlicePub and BobPubTxIn: Bob(5) + __ Bob can Broadcast Bob can Broadcast Tx1Bob: {5, 5} Alice can Broadcast Tx1Alice: {5, 5}
  37. 37. Tx1Bob: {5, 5} TxIn: AliceSig, missing BobSig Out(5): AlicePub Out(5): {Timelock to BobPub} or {AlicePub and BobTmp1Pub} Alice が Deposix Tx に署名・共有: Tx1Bob 系 Tx0: not broadcasted TxIn: Alice(5) + sig Out(10): AlicePub and BobPubTxIn: Bob(5) + __ Bob can Broadcast Bob can Broadcast Tx1Alice: {5, 5} Alice can Broadcast Alice 収益: 5 BTC
  38. 38. Tx1Bob: {5, 5} TxIn: AliceSig, missing BobSig Out(5): BobPub Out(5): {Timelock to AlicePub} or {BobPub and AliceTmp1Pub} Alice が Deposix Tx に署名・共有: Tx1Alice 系 Tx0: not broadcasted TxIn: Alice(5) + sig Out(10): Alice and BobTxIn: Bob(5) + __ Bob can Broadcast Bob can Broadcast Tx1Alice: {5, 5} Alice can Broadcast Alice 収益: 1000 時間後 5 BTC
  39. 39. Bob が Opening Tx を Broadcast Tx0: broadcasted TxIn: Alice(5) + sig Out(10): AlicePub and BobPubTxIn: Bob(5) + sig Bob can Broadcast Tx1Alice: {5, 5} Alice can Broadcast On Block Not On Block (Yet) Tx1Bob: {5, 5}
  40. 40. Alice が Bob に 1 BTC 支払う {5, 5} もしくは、 {4, 6} のみが成立するようにしながら、 最後に {4, 6} のみが有効になるように
  41. 41. Alice が、更新したBob用 払い戻し Tx 作成共有 Out(10): AlicePub and BobPub Bob can Broadcast Tx1Alice: {5, 5} Alice can Broadcast Tx1Bob: {5, 5} Tx2Bob: {4, 6} TxIn: AliceSig, missing BobSig Out(4): AlicePub Out(6): {Timelock to BobPub} or {AlicePub and BobTmp2Pub} Bob can Broadcast
  42. 42. Bob も、更新した Alice 用払い戻し用の Tx 作成共有 Out(10): AlicePub and BobPub Tx1Alice: {5, 5} Alice can Broadcast Bob can Broadcast Tx1Bob: {5, 5} Bob can Broadcast Tx2Bob: {4, 6} Alice can Broadcast Tx2Alice: {4, 6}
  43. 43. Alice が、Bob に AliceTmp1 の秘密鍵を渡す Out(10): AlicePub and BobPub Alice can Broadcast Bob can Broadcast Tx1Bob: {5, 5} Bob can Broadcast Tx2Bob: {4, 6} Alice can Broadcast Tx2Alice: {4, 6} Tx1Bob: {5, 5} TxIn Out(5): BobPub Out(5): {Timelock to AlicePub} or {BobPub and AliceTmp1Pub} TxIn: AliceTmp1Sig And BobSig Bob can Broadcast TxIn: AliceSig Alice can Broadcast After 1000 hours Alice の収益: 0 BTC
  44. 44. Bob も、Alice に BobTmp1 の秘密鍵を渡す Out(10): AlicePub and BobPub Tx1Alice: {5, 5} Alice can Broadcast Bob can Broadcast Tx1Bob: {5, 5} Bob can Broadcast Tx2Bob: {4, 6} Alice can Broadcast Tx2Alice: {4, 6} All to Bob Bob can Broadcast All to Alice Alice can Broadcast 0.5, 0.5 Bob can boardcast After 1000 hours 0.5, 0.5 Alice can boardcast After 1000 hours
  45. 45. Channel を close する
  46. 46. Close 用 Tx 作ってそれを Broadcast Out(10): AlicePub and BobPub Bob can Broadcast TxNBob: {4, 6} Alice can Broadcast TxNAlice: {4, 6} TxIn: AliceSig, BobSig Out(4): AlicePub Out(6): BobPub
  47. 47. Channel が閉じられた後 Out(10): AlicePub and BobPub Commit Tx TxIn: AliceSig, BobSig Out(4): AlicePub Out(6): BobPub On Block Not On Block (Yet)
  48. 48. 2.2 Lightning Network
  49. 49. PaymentChannel をネットワーク化する A C B D E F H G I
  50. 50. Lightning Network 具体的に何をやっているか ● Alice が Charlie に送る ● Alice -> Bob -> Charlie ● 方法: ○ Tmp (秘密鍵) があれば完了する送金、 TimeLock で自分自身に遅りながら。 ○ Alice -(7 days)-> Bob -> (5 days) -> Charlie で Tx を作って、 Charlie は自分に届いたら Secret をバラまく。
  51. 51. Lightning Network の概念的な図示 Alice Bob Charlie or BobSig and CharlieTmpToken Timelock to AliceSig CharlieSig and CharlieTmpToken Timelock to BobSig or
  52. 52. Timelock on Payment Channel TxNBob: {5, 5} TxIn: AliceSig, missing BobSig Out(5): AlicePub Out(5): {Timelock to BobPub} or {AlicePub and BobTmpPub} TxnBob: {4, 5, 1} TxIn: AliceSig, missing BobSig Out(4): AlicePub Out(5): {Timelock to BobPub} or {AlicePub and BobTmpNPub} Out(1): {Timelock to AlicePub} or {BobPub and CharlieTmpToken}
  53. 53. 3. Segwit が何故必要か
  54. 54. L.N. は TxOut が変わらないことを前提にしている ● TxIn は TxOut を (Txid, n) で参照する。 ● TxId は、segwit を考えない場合は、以下で計算される sha256^2( Tx という TxIn と TxOut の集合的データ ) -> TxIn の署名部分が変わるたびに TxId も変わる。
  55. 55. なので: 署名部分(scriptsig) を別領域へ Inputs Outputs Sig Sig TxId Inputs Outputs Sig Sig TxId WitnessTxId Witness Merkle Tree へ
  56. 56. まとめ ● Bitcoin の Tx の、特に script まわりを見てきた ● Lightning Network が、 UTXO のロック的側面を利用して、ゲーム木的に支払いを 実装していることを説明した ● Lightning Network には segwit が必須であることを見た。
  57. 57. ご静聴ありがとうございました!

×