Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ブロックチェーン×プライバシーと暗号技術
Search
shigeyuki azuchi
October 11, 2018
Technology
1
900
ブロックチェーン×プライバシーと暗号技術
e-ZUKA Tech Night Vol. 45の発表スライド
shigeyuki azuchi
October 11, 2018
Tweet
Share
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
Pay to Anchorと1P1Cリレー
azuchi
0
2
プロアクティブ秘密分散法
azuchi
0
6
v3トランザクションリレー
azuchi
0
13
ランポート署名
azuchi
0
41
BitVM
azuchi
0
51
Replacement Cycling Attack
azuchi
0
49
Bitcoinのタイムロックの仕組み
azuchi
0
37
Inner Product Argument
azuchi
0
77
Codex32
azuchi
0
31
Other Decks in Technology
See All in Technology
小学3年生夏休みの自由研究「夏休みに Copilot で遊んでみた」
taichinakamura
0
170
.NET 9 のパフォーマンス改善
nenonaninu
0
1.1k
UI State設計とテスト方針
rmakiyama
2
650
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
120
生成AIをより賢く エンジニアのための RAG入門 - Oracle AI Jam Session #20
kutsushitaneko
4
260
第3回Snowflake女子会_LT登壇資料(合成データ)_Taro_CCCMK
tarotaro0129
0
200
社内イベント管理システムを1週間でAKSからACAに移行した話し
shingo_kawahara
0
190
kargoの魅力について伝える
magisystem0408
0
210
podman_update_2024-12
orimanabu
1
280
KubeCon NA 2024 Recap / Running WebAssembly (Wasm) Workloads Side-by-Side with Container Workloads
z63d
1
250
なぜCodeceptJSを選んだか
goataka
0
160
あの日俺達が夢見たサーバレスアーキテクチャ/the-serverless-architecture-we-dreamed-of
tomoki10
0
480
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
133
9k
Visualization
eitanlees
146
15k
Done Done
chrislema
181
16k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Gamification - CAS2011
davidbonilla
80
5.1k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
Code Reviewing Like a Champion
maltzj
520
39k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Designing for Performance
lara
604
68k
Practical Orchestrator
shlominoach
186
10k
Transcript
Copyright ©2018 chaintope, Inc. all rights reserved. e-ZUKA Tech Night
Vol. 45 ブロックチェーン×プライバシーと暗号技術 2018/10/11 chaintope, Inc Shigeyuki Azuchi
Copyright ©2018 chaintope, Inc. all rights reserved. 自己紹介 • Shigeyuki
Azuchi • 株式会社chaintope CTO • BitcoinプロトコルのRuby実装「bitcoinrb」 • Open Assets ProtocolのRuby実装 「openassets-ruby」 • 共著 「ブロックチェーン・プログラミング 仮想通貨入門」 • ブログ「Develop with pleasure!」 https://techmedia-think.hatenablog.com/
Copyright ©2018 chaintope, Inc. all rights reserved. プライバシーの課題 • どのアドレスからどのアドレスへ支払われた
• どのアドレスにいくら支払われた • どんな契約が行われた
Copyright ©2018 chaintope, Inc. all rights reserved. 取引量の秘匿
Copyright ©2018 chaintope, Inc. all rights reserved. 取引されるBitcoinの量 量を秘匿するためにはこのデータを秘匿する必要がある 取引するBitcoinの量は、
トランザクションの各アウトプットにロック スクリプトと一緒に明示的に記載される。 Version 4 bytes TxIn Count 1-9 bytes TxIn variable TxOut Count 1-9 bytes TxOut variable Locktime 4 bytes value 8 bytes ScriptPubkey length 1-9 bytes ScriptPubkey variable “value”: 50000
Copyright ©2018 chaintope, Inc. all rights reserved. Pedersen Commitment 1991年にPedersenによって提案された、離散対数を利用した
秘密分散の仕組み https://www.cs.cornell.edu/courses/cs754/2001fa/129.PDF • シンプルなcommitment commitment = SHA-256(blinding_factor || data) • commitmentの加算 C(BF1, data1) + C(BF2, data2) == C(BF1 + BF2, data1 + data2) C(BF1, data1) − C(BF1, data1) == 0 data1〜3={1, 1, 2}、BF1〜BF3={5, 10, 15}の場合 C(BF1, data1) + C(BF2, data2) - C(BF3, data3) == 0 C(1 + 1, 5 + 10) − C(2, 15) == 0
Copyright ©2018 chaintope, Inc. all rights reserved. Confidential Transaction 楕円曲線を利用したPedersen
commitmentを利用して、量を公開鍵として管理 • 楕円曲線暗号の秘密鍵(x)と公開鍵(Pub) Pub = xG (※Gは楕円曲線のベースグループ) • 楕円曲線の準同型の加法性 Pub1 + Pub2 = (x1 + x2)G • 楕円曲線を利用したcommitment commitment = xG + aH ※ xは秘密のblinding factor, a はコミットするコインの量 HはGとは異なるベースグループでGから計算する H = to_point(SHA256(ENCODE(G))) ※楕円曲線上の点Hのx座標が(SHA256(ENCODE(G)))
Copyright ©2018 chaintope, Inc. all rights reserved. Bitcoin Transactionに適用 value
8 bytes ScriptPubkey length 1-9 bytes ScriptPubkey variable “value”: 50000 commitment = xG + aH (32 bytes) “commitment”: “08e6cb1c2118fa492df6782f84d496882ced45b4e759d7cafd507cc2211d217cef” xはBlinding Factor aが送金するBitcoinの量 valueをintegerからcommitmentに変更する ※ commitment = 公開鍵(楕円曲線上の点) Blinding Factor(x)とaを知らない第三者は Tx内のコインの量が分からない
Copyright ©2018 chaintope, Inc. all rights reserved. 量の検証 秘密を知らないユーザーには送金される量は分からないが、そのトランザクション で送金されている量が正しい量かは誰もが検証できる必要がある。
(インプットの量 − アウトプットの量 = 手数料) インプットのcommitment − アウトプットのcommitment = 0 になればいい。 (※但し、手数料は明示的に設定する必要がある。) 楕円曲線の点(x, y)の減算は、逆元を(x, -y)を加算する。 問題点 (1 + 1) − (-5 + 7) == 0 も成立し、もともとインプットは2BTCしかないが、7 BTCのアウトプットが 成立(=通貨発行)してしまう。 ※ グループGは巡回群なのでオーバーフローさせることでマイナスのような振る舞いをする。 commitmentがマイナスの値でない(0〜2^64の範囲である)ことを証明する Range Proofを別途提供する必要がある。 (In1 + In2 + In3 + … ) - (Out1 + Out2 + Out3 + … + fee * H) == 0
Copyright ©2018 chaintope, Inc. all rights reserved. 取引先の秘匿
Copyright ©2018 chaintope, Inc. all rights reserved. ミキシング Version 4
bytes TxIn Count 1-9 bytes TxIn variable TxOut Count 1-9 bytes TxOut variable Locktime 4 bytes 複数のユーザーの送金を1つのトランザクションにまとめる (ミックスする)ことで、トランザクショングラフを複雑にし、 送金先を分かりづらくする。 ※管理者が送金元と送金先を知ることができるのが、 プライバシーリスク
Copyright ©2018 chaintope, Inc. all rights reserved. TumbleBit ① Tumblerを利用した決済に合意
② ボブはTumberとの PCにコインをロック ③ アリスはTumberとの PCにコインをロック ④ ボブはTumberから パズルzを受け取る。 RSAパズルを解かないと キャッシュアウト不可能。 Z B(Z) B(Z) ⑤ アリスはTumberに B(Z)の回答B(ε)を求める。 B(ε) B(ε) ⑥ ボブはB(ε)を変換して真の回答 εを入 手。 ε Puzzle-Promise Protocol
Copyright ©2018 chaintope, Inc. all rights reserved. 取引内容の秘匿
Copyright ©2018 chaintope, Inc. all rights reserved. Cross-chain Atomic Swap
HTLC(Hashed Time Lock Contract) シークレットとタイムロックを利用したAtomic Swapプロトコル アリスはLitecoin上でシークレットAを公開してLTCを入手し、 ボブは公開されたAを使ってBTCを入手する。 ※コインを入手する際にスクリプトは公開されブロックチェーンに記録されるため、 Atomic Swapを行ったことは誰もが知ることになる アリスはBitcoinを以下のアンロック条件のスクリプトに送る。 • H(A)のプリイメージ=シークレットAが分かればボブは BTCを入手できる。 • 10日経過したらアリスはBTCを入手できる。 Secret A H(A) ボブはLTCを以下のアンロック条件のコントラクトに送る。 • H(A)のプリイメージ=シークレットAが 分かればアリスはLTCを入手できる。 • 5日経過したらボブはLTCを入手できる。 BTC/LTCを交換
Copyright ©2018 chaintope, Inc. all rights reserved. Schnorr署名 公開鍵と署名の集約特性を持つデジタル署名方式 •
楕円曲線のジェネレータ: G • 秘密鍵: x • 公開鍵: P = xG • ハッシュ関数: H() • メッセージ: m 【署名の生成】 1. ランダムなnonce k を選択 2. kを秘密鍵として楕円曲線上の点R = kGを計算 3. s = k + H(P, R, m)x を計算 4. (R, s)が署名データ 【署名の検証】 sG = R + H(P, R, m)P が成立するか検証 Bitcoinへの導入の提案もスタート https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
Copyright ©2018 chaintope, Inc. all rights reserved. Adaptor Signature Atomic
Swapで必要なハッシュのプリイメージの交換を 代替するのがAdaptor Signature • 通常のSchnorr署名 (R, s) : s = k + H(P, R, m)x • Adaptor Signature (R, s’, T): s’ = k + t + H(P, R, m)x ※いずれもRは同じ値 Adaptor Signature s’ と 署名 s が揃うと t が計算できる s’ - s = t T = tG → tがプリイメージ、Tがハッシュの代替
Copyright ©2018 chaintope, Inc. all rights reserved. Adaptor Signatureを利用したAtomic Swap
③ アリスはランダムなシークレットt (T = tG)を生成し、マルチシグの 署名を作成するヒントが入ったAdapter Signatureを作ってボブに送る。 ※ 両方のチェーンでそれぞれのPとRを使って同様のことを行う。 このとき同じ t を使用する。 s’ = k1 + t + H(P, R, m)x1 BTC/LTCを交換 (R, s', T) ②各チェーンで相手に送金する未署名のTxを作成 T = tG ④ ボブはマルチシグの署名データの一部をアリスに渡す sB = k2 + H(P, R, m)x2 ⑥ ボブはアリスの署名 s を使って t の値を知る。 t = s’ + sB - s t が分かるとマルチシグをアンロックするのに必要な アリス側の署名を計算できる。 sA = s’’ - t これでもう1方のチェーンのコインを入手する。 ⑤アリスはボブから受け取ったsBを使って、マルチシグの署名を完成させる。 s = s’ + sB - t = k1 + k2 + H(P, R, m)(x1 + x2) 署名(R, s)を完成させコインを入手するTxをブロードキャストする。 鍵ペア P1 = x1G nonce R1 = k1G 鍵ペア P2 = x2G nonce R2 = k2G マルチシグ公開鍵 P = P1 + P2 nonce R = R1 + R2 (※ P, R は各チェーンで異なる) ① P 宛にBTCをロック ① P’ 宛にLTCをロック Tx Tx’ sB Tx’ (R, s) t
Copyright ©2018 chaintope, Inc. all rights reserved. 最後に エンジニア向けオンライン・コミュニティ ブロックチェーンの技術要素について、初心者向け、
最先端情報などを動画で配信していきます!