最近のBitcoinとこれからのBitcoin

最近のBitcoinとこれからのBitcoin

Transcript

1. 2020年のブロックチェーン業界を考える
 
 最近のBitcoinとこれからのBitcoin
 Shigeyuki Azuchi
 2019.10.16

2. Copyright © 2019 chaintope Inc. All rights reserved. 自己紹介
 2 • 安土 茂亨（Shigeyuki Azuchi）
 • 株式会社Chaintope CTO
 
 • Bitcoin関連のRubyライブラリの実装
 ◦ https://github.com/chaintope/bitcoinrb
 ◦ https://github.com/chaintope/schnorrrb
 ◦ https://github.com/chaintope/utreexorb
 ◦ https://github.com/chaintope/c-lightningrb
 
 • 共著
 「ブロックチェーン・プログラミング 仮想通貨入門」
 • ブログ「Develop with pleasure!」
 https://techmedia-think.hatenablog.com/
 • GBEC
 https://goblockchain.network/

3. Copyright © 2019 chaintope Inc. All rights reserved. Bitcoinの直近の変更
 3 Bitcoinの直近のソフトフォークは
 2017年8月24日にアクティベートされたSegwitが最後
 
 • chainsate DBの変更によるパフォーマンス改善(0.15.0)
 • マルチウォレットサポート（0.15.0）
 • Bech32アドレスのサポート（0.16.0）
 • 【BIP-159】プルーニングピアからのBlock, Txリレーのサポート （0.16.0-0.17.0）
 • 【BIP-174】PSBTのサポート（0.17.0）
 • ECDSA署名のLOW R適用（0.17.0）
 • 【BIP-125】RBFのGUIデフォルトサポート
 （0.12.0-0.18.1）
 • etc..
 Segwitのアクティベートで 
 Lightning Networkが稼働可能に！ 

4. Copyright © 2019 chaintope Inc. All rights reserved. Lightning Network
 4
5. Copyright © 2019 chaintope Inc. All rights reserved. 2018年1月時点のネットワーク
 5 ノード数： 199
 チャネル数： 524
 キャパシティ：2.74932962 BTC

6. Copyright © 2019 chaintope Inc. All rights reserved. 2019年1月時点のネットワーク
 6 ノード数： 2,514
 チャネル数： 18,906
 キャパシティ：560.47997807 BTC

7. Copyright © 2019 chaintope Inc. All rights reserved. 2019年10月時点のネットワーク
 7 ノード数： 4,868
 チャネル数： 31,096
 キャパシティ：805.67232074 BTC

8. Copyright © 2019 chaintope Inc. All rights reserved. Protocol Updateの候補
 8
9. Copyright © 2019 chaintope Inc. All rights reserved. Schnorr 署名のサポート
 9 Schnorr署名
 • 秘密鍵：x、公開鍵：P = xG
 • 暗号学的ハッシュ関数：H()
 • 署名対象のメッセージ：m
 
 
 【署名の生成】
 1. ランダムなnonce kを選択
 2. R = kGを計算
 3. s = k + H(R||P||m) x を計算
 4. （R, s）が署名データ
 
 【署名の検証】
 sG = R + H(R||P||m)P 
 を検証
 
 署名値sは単純な加算式なので、
 異なる鍵ペアを使って作成した署名を集約できる。
 
 • P1 = x1G, R1 = k1G
 • P2 = x2G, R2 = k2G
 
 1. P = P1 + P2, R = R1 + R2 に合意
 2. それぞれsを計算
 a. s1 = k1 + H(R||P||m)x1
 b. s2 = k2 + H(R||P||m)x2
 3. s = s1 + s2 = k1 + k2 + H(R||P||m)(x1 + x2)
 4. sG = R + H(R||P||m)P が成立する。
 

10. Copyright © 2019 chaintope Inc. All rights reserved. Schnorr 署名のサポート
 10 • 使用する楕円曲線は既存のECDSAベースのものと同じ
 （secp256k1）
 • Schnorr署名のメリット
 ◦ 安全性の証明がある。
 ◦ 署名のmalleabilityが解消される。
 ◦ 署名に線形特性がある。
 OP_2 <P1> <P2> OP_2 OP_CHECKMULTISIG
 というマルチシグスクリプトが不要になり
 <P(P1 + P2)> OP_CHECKSIG
 で済み、署名も１つだけになりサイズ圧縮に
 ◦ 秘密分散と組み合わせてt-of-nのような
 閾値署名のサポートも
 LNのFunding Outputも
 通常の送金と区別不能に 

11. Copyright © 2019 chaintope Inc. All rights reserved. Taproot
 11 マルチパーティコントラクト
 OP_IF
 OP_2 <P1> <P2> OP_2 OP_CHECKMULTISIG 
 OP_ELSE
 <locktime> OP_CSV OP_DROP <P1> OP_CHECKSIG 
 OP_ENDIF
 公開鍵を集約 C = P1 + P2
 別の条件のスクリプトをSとし
 H(C||S)Gを計算
 P = C + H(C||S)G
 を計算しコインをロック
 マルチパーティコントラクトを 
 単一の公開鍵にエンコードする 
 • マルチパーティ（Key-path）でアンロックする場合
 P1とP2に対応する秘密鍵で生成した署名にH(C||S)を加算する。
 s = k1 + k2 + H(R||P||m)(x1 + x2 + H(C||S))
 • スクリプトを使って（Script-path）アンロックする場合
 CとSを提供し、P == C + H(C||S)Gが一致したら、Sがアンロックスクリプトとして利用 可能に。

12. Copyright © 2019 chaintope Inc. All rights reserved. Taproot
 12 スクリプト部はアンロックの条件毎に
 ツリーを使って構成される
 P = C + tG
 Script A
 Script B
 Script C
 Hash_TapLeaf 
 Hash_TapLeaf 
 Hash_TapLeaf 
 Script D
 Script E
 Hash_TapLeaf 
 Hash_TapLeaf 
 AB
 Hash_TapBranch 
 CD
 Hash_TapBranch 
 CDE
 Hash_TapBranch 
 ABCDE
 Hash_TapBranch 
 t
 Hash_TapTweak 
 Pubkey C
 スクリプトパスを使ってアンロックする場合は、
 スクリプトとtを計算するためのパス（ハッシュ）を提供す る
 実際の使用条件のみを開示するため、 
 • 他の条件を秘匿でき 
 プライバシーの向上に 
 • 全スクリプトの記載が不要で、デー タスペースの節約に 

13. Copyright © 2019 chaintope Inc. All rights reserved. SIGHASH-NOINPUT
 13 Txの署名対象データ【BIP-143】 nVersion hashPrevouts（全入力のOutpointから生成した ハッシュ） hashSequence（全入力のsequenceから生成した ハッシュ） outpoint（署名対象の入力のOutpoint） scriptCode value（署名対象の入力が持つコインの量） nSequence（署名対象の入力のsequence） hashOutputs（全出力から生成したハッシュ） nLocktime sighash type 署名時にインプットが参照する前のトランザクション 
 アウトプット(UTXO)の参照情報（TXID, index）が
 全て空にする。
 署名はトランザクションの OutPointにコミットしなくなり
 署名後にインプットが参照する OutPointの変更が
 可能になる。
 空（0x00）
 署名済みTx Input Output TxA Input Output TxB Input Output 変更可 ※ リバインド可能なのは同じ witness
 　要素でアンロック可能な UTXOのみ
 eltooスタイルのLightning Networkが実装可能に！
 https://goblockchain.network/2018/11/eltoo_and_sighash_noinput/

14. Copyright © 2019 chaintope Inc. All rights reserved. Compact Block Filter
 14 Filter Header
 Filter Header
 Filter Header
 Filter Header
 double-SHA256
 （GCSFilter）32 bytes
 前のフィルタヘッダ
 32 bytes
 double-SHA256
 Block
 Tx
 Tx
 Tx
 Tx
 全Txから以下を抽出 
 • インプットが参照するスクリプト 
 • アウトプットスクリプト 
 各要素を入力として 
 Golomb-coded set Filter 
 （GCS Filter）を生成
 GCS Filter
 ※ 既存のBloom Filterを利用したフィルタの仕組みは
 クライアント（軽量ノード）毎にフィルタを作成するが、Compact Block Filterではブロック毎にフィルタを作成する。
 既存のBlock Headerと同様に、フィルタのチェーンが形成され伝播される。 
 軽量ノードはフルノードから受信したフィルタを使って、自身に関連する 
 Txがあるか判定する。合致した場合は該当ブロックをダウンロードする。 
 フルノードの負荷の低減、軽量クライアントのプライバシーの向上に。
 https://goblockchain.network/2019/09/compact_block_filter/

15. Copyright © 2019 chaintope Inc. All rights reserved. OP_SECURETHEBAG
 15 コインの使用方法を制限するopcode OP_SECURETHEBAG
 Spend Tx
 Input
 Output
 <32バイトのハッシュ> OP_SECURETHEBAG
 UTXOのscriptPubkeyに
 OP_SECURETHEBAG が
 含まれている場合
 コインを使用するトランザクションの 
 Outputは
 • scriptPubkey
 • value
 予め決められた内容 
 （32バイトのハッシュ） 
 と一致しなければならない。 
 OP_SECURETHEBAGを使うと、
 • コインの金庫を実装できる。
 • 条件に応じて送金額を制御できるようになる。
 
 ※ Taprootと一緒に導入なるか？（Fungibilityを損う？）

16. Copyright © 2019 chaintope Inc. All rights reserved. Lightning Networkの改善
 16
17. Copyright © 2019 chaintope Inc. All rights reserved. Atomic Multi-Path Payments
 17 BP = s1 ^ s2 ① ベースプリイメージ BPを作成し、xorを計算してBPが得 られるような値s1, s2を得る。
 （秘密分散の意図）
 使用チャネル数 n = 2
 送金額 V = v1(5) + v2(1)
 アトミック決済用の一意の ID
 ②部分プリイメージ ri = H(BP || i) と
 各チャネルで使用するペイメントハッシュ 
 hi = H(ri) を計算する。
 hop payload （ID, n, s1） hop payload （ID, n, s2） hop payload （ID, n, s2） hop payload （ID, n, s2） hop payload （ID, n, s1） ③各チャネルでhiのプリイメージが分かれば 
 資金を入手できるHTLC決済をスタートする。 
 ※必ず経路毎に異なるプリイメージを使用する。 
 各ホップのペイロードには、AMPの使用を
 通知するfeature bitがセットされる。
 BP = s1 ^ s2 ④ボブは全ての部分支払いを受信し、 
 そのsiを全て集めてBPを復元する。
 BPを復元できたら、各チャネルの支払いを 
 受け取るのに必要な riを算出できる。
 チャネル毎のキャパシティでは送金額に満たないものの、複数のチャネルを使えば送金額 を満たす場合に、複数の経路を使用した支払いをアトミックに行う仕組み。

18. Copyright © 2019 chaintope Inc. All rights reserved. Trampoline Payments
 18 Light
 Client
 チャネル数が数百万オーダーになると、軽量クライアントがノードネットワークの最新情報を 維持し、経路を計算するのが困難になる（メモリ、ネットワーク帯域）
 
 Trampoline
 Node
 LN Node
 LN Node
 LN Node
 LN Node
 Trampoline
 Node
 LN Node
 LN Node
 LN Node
 軽量クライアントは
 近いノード情報のみを保持 
 受信者までの経路は、 
 Trampoline Nodeが
 経路計算を代替

19. Copyright © 2019 chaintope Inc. All rights reserved. Channel Factories
 19 Lightning Networkもチャネルとオープン/クローズのオンチェーンTxが発生し、
 マスアダプションのためにはオンチェーンキャパシティの増加が求められる。
 • Channel Factory
 資金をマルチパーティのマルチシグにロックする（on-chain）
 • Subchannels
 FactoryのパルチパーティのUTXOをインプットとして、
 2者間のペイメントチャネルをセットアップする（off-chain）
 チャネル開閉のオンチェーンTxを不要にする
 

20. Copyright © 2019 chaintope Inc. All rights reserved. Scriptless Scripts
 20
21. Copyright © 2019 chaintope Inc. All rights reserved. Adaptor Signature
 21 • 通常のSchnorr署名
 （R, s）: R = kG, s = k + H(P, R, m) x 
 • Adaptor Signature
 （R, s’, T）: R = kG, s’ = k + t + H(P, R, m) x, T = tG
 
 Schnorr署名の一部にシークレット値(t)を加えた署名を事前に作成/交換し、
 有効なSchnorr署名(R, s)が公開されたらシークレットの値が分かり(t = s’ - s)、その値を 使って別のコインがアンロックされる仕組み。
 
 
 あるTxの署名を完成させたら別のTxの署名に必要なシークレット値が分かる
 コインのAtomic Swap プロトコルに利用可能。
 
 コントラクト(HTLCs)でやっていたことをデジタル署名にエンコード
 外部からは通常の送金に見え(privacy)、Txのサイズも小さくなる(手数料減)
 
 参考：Adaptor Signatureを利用したAtomic Swap（Schnorr版）
 https://goblockchain.network/2018/12/adaptor_signature/ 

22. Copyright © 2019 chaintope Inc. All rights reserved. 2P-ECDSA
 22 Schnorr署名をベースとしたScriptless Scriptsが注目される中、既存 のECDSAベースでそれを実現する研究も加速
 ※ ECDSA署名にはSchnorrのような線形特性はないため単純な 署名の集約はできない
 2017年, Yehuda Lindellにより、Paillier暗号を
 利用した2者間のマルチシグをECDSAで
 Scriptlessに実現するプロトコルが公開される。
 （Multisig, Atomic Swap, Multi-Hop Locks）
 
 
 【参考】
 • 高速で安全な2者間のECDSA署名 
 https://goblockchain.network/2018/10/ecdsa_2-of-2_multisig/ 
 • Adaptor Signatureを利用したAtomic Swap（ECDSA版） 
 https://goblockchain.network/2019/01/adaptor_signature-ecdsa/ 

23. Copyright © 2019 chaintope Inc. All rights reserved. 2P-ECDSA
 23 
 タイプ
 仮定
 署名ラウンド
 署名時間
 [L17]
 2/2
 ECDSA, Paillier
 4
 ミリ秒
 [GG18]
 t/n
 ECDSA, Strong RSA 
 9
 ミリ秒
 [LNR18]
 t/n
 ECDSA, DDH
 8
 ミリ秒
 [DKLS18]
 2/n
 ECDSA
 2
 ミリ秒
 [DKLS19]
 t/n
 ECDSA
 Log(t) + 6
 ミリ秒
 [CCLST19]
 2/2
 ECDSA, Class groups 
 4
 ミリ秒
 [SA19]
 n/n
 ECDSA
 1
 
 [DKOSS19]
 t/n
 ECDSA
 1
 ミリ秒
 2017年, Yehuda Lindellのペーパー発表以降、多くの
 ECDSAベースの閾値署名に関するペーパーが発表される。
 ※ Scaling Bitcoin 2019 Threshold Scriptless Scriptsの発表より引用 

24. Copyright © 2019 chaintope Inc. All rights reserved. その他
 24
25. Copyright © 2019 chaintope Inc. All rights reserved. Utreexo
 25 フルノードの管理するUTXOセット（現在約4GB）を数KBほどの
 ストレージで管理可能にするハッシュベースのアキュムレーター
 
 
 
 
 
 
 
 
 
 
 
 
 
 • 【参考】ハッシュベースのアキュムレーター Utreexoの仕組み
 https://goblockchain.network/2019/08/utreexo/ 
 OutPoint A
 OutPoint B
 OutPoint C
 ・・・
 OutPoint XXXXX
 現在は、UTXOのOutPoint(txid, index)を
 そのままストレージで管理しており、
 34bytes/UTXOストレージを消費する。
 1
 2
 3
 4
 5
 6
 7
 UTXOをリーフとして完全二分木を構成し、
 各ツリーのマークルルートのみを保持する。
 UTXOを使用する際は、署名などに加えて
 そのUTXOのInclusion Proofを提供する。
 フルノード稼働デバイスのHW要件の緩和に 

26. Copyright © 2019 chaintope Inc. All rights reserved. Erlay
 26 冗長的なトランザクションの伝播プロトコルを改善する
 新しいトランザクション伝播プロトコル
 Peer 1
 Peer 2
 ① Txを受信
 ② Txの検証を実施
 inv
 ③ inv：hash(Tx)を接続中のピアに送信
 ④ Peer 2が対象のTxをまだ持っていない
 場合、getdata：hash(Tx)をPeer 1に送信
 ⑤ Txメッセージで応答
 Tx
 getdata
 Tx
 既存のFlooding Tx Relay
 • invメッセージ（32 bytes/tx）を接続中の全 てのピアに送信するため、大半のピアは 既に持っているTxの通知を受け取ることに なる。
 • Txリレーの88％、P2Pメッセージ全体の 44% が冗長的なデータとなり、ネットワーク帯域 の無駄な使用。
 • ネットワーク全体への伝播スピードは 効率 的

27. Copyright © 2019 chaintope Inc. All rights reserved. Erlay
 27 Txのリレーを2段階に分離
 ① Low-fanout Floodingフェーズ
 Flooding方式は拡散という意味では効率的であるため、Public ノードのアウトバウンド接続のピアに対してのみFloodingでTxを リレーする。
 
 ② Set-reconciliationフェーズ
 Low-fanout Floodingのみではネットワーク全体に
 伝播できないため、それを補完するフェーズ。
 各ノードはローカルの状態と接続中のピアの状態を
 定期的に比較し、その差分を計算し不足Txを要求する。
 
 Peer 1
 sketch
 Peer 2
 sketch
 XOR
 diff
 各ノードが持つトランザクションの短縮 TXIDのリストからSketchを作成 
 Peer 1
 Peer 2
 Peer 1
 sketch
 Peer 2
 sketch
 =
 両ノードのSketchのXORを取り、差分を計 算し、差分から自身に不足しているTXIDの リストを復元し、要求 
 Sketchの送信
 不足Txの要求、Pee1の不足Txを送信 
 Minisketchでローカルの 
 状態をエンコード