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
40
BitVM
azuchi
0
51
Replacement Cycling Attack
azuchi
0
49
Bitcoinのタイムロックの仕組み
azuchi
0
37
Inner Product Argument
azuchi
0
77
Codex32
azuchi
0
30
Other Decks in Technology
See All in Technology
フロントエンド設計にモブ設計を導入してみた / 20241212_cloudsign_TechFrontMeetup
bengo4com
0
1.9k
2024年にチャレンジしたことを振り返るぞ
mitchan
0
130
開発生産性向上! 育成を「改善」と捉えるエンジニア育成戦略
shoota
2
320
Qiita埋め込み用スライド
naoki_0531
0
3.7k
統計データで2024年の クラウド・インフラ動向を眺める
ysknsid25
2
840
podman_update_2024-12
orimanabu
1
270
社外コミュニティで学び社内に活かす共に学ぶプロジェクトの実践/backlogworld2024
nishiuma
0
260
多領域インシデントマネジメントへの挑戦:ハードウェアとソフトウェアの融合が生む課題/Challenge to multidisciplinary incident management: Issues created by the fusion of hardware and software
bitkey
PRO
2
100
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
280
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
120
コンテナセキュリティのためのLandlock入門
nullpo_head
2
320
【re:Invent 2024 アプデ】 Prompt Routing の紹介
champ
0
140
Featured
See All Featured
A Philosophy of Restraint
colly
203
16k
Into the Great Unknown - MozCon
thekraken
33
1.5k
Being A Developer After 40
akosma
87
590k
It's Worth the Effort
3n
183
28k
KATA
mclloyd
29
14k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Designing Experiences People Love
moore
138
23k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
Site-Speed That Sticks
csswizardry
2
190
Building an army of robots
kneath
302
44k
Raft: Consensus for Rubyists
vanstee
137
6.7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
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. 最後に エンジニア向けオンライン・コミュニティ ブロックチェーンの技術要素について、初心者向け、
最先端情報などを動画で配信していきます!