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
Mimblewimble
Search
shigeyuki azuchi
March 29, 2019
Technology
0
52
Mimblewimble
GBEC動画解説コンテンツのスライドです。
https://goblockchain.network/2019/03/mimblewimble/
shigeyuki azuchi
March 29, 2019
Tweet
Share
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
プロアクティブ秘密分散法
azuchi
0
3
v3トランザクションリレー
azuchi
0
8
ランポート署名
azuchi
0
33
BitVM
azuchi
0
46
Replacement Cycling Attack
azuchi
0
44
Bitcoinのタイムロックの仕組み
azuchi
0
33
Inner Product Argument
azuchi
0
72
Codex32
azuchi
0
27
PSBT
azuchi
0
66
Other Decks in Technology
See All in Technology
Amazon Personalizeのレコメンドシステム構築、実際何するの?〜大体10分で具体的なイメージをつかむ〜
kniino
1
100
OCI 運用監視サービス 概要
oracle4engineer
PRO
0
4.8k
AWS Lambdaと歩んだ“サーバーレス”と今後 #lambda_10years
yoshidashingo
1
170
Terraform未経験の御様に対してどの ように導⼊を進めていったか
tkikuchi
2
440
New Relicを活用したSREの最初のステップ / NRUG OKINAWA VOL.3
isaoshimizu
2
610
rootlessコンテナのすゝめ - 研究室サーバーでもできる安全なコンテナ管理
kitsuya0828
3
390
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
AIチャットボット開発への生成AI活用
ryomrt
0
170
Zennのパフォーマンスモニタリングでやっていること
ryosukeigarashi
0
100
EventHub Startup CTO of the year 2024 ピッチ資料
eventhub
0
120
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.9k
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Being A Developer After 40
akosma
87
590k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Gamification - CAS2011
davidbonilla
80
5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Unsuck your backbone
ammeep
668
57k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Faster Mobile Websites
deanohume
305
30k
Designing for Performance
lara
604
68k
Transcript
Mimblewimble
1 Mimblewimble 2016年にTom Elvis JedusorがIRCに投稿した 新しいブロックチェーンのコンセプト https://scalingbitcoin.org/papers/mimblewimble.txt • スクリプトを持たず公開鍵暗号を使った署名検証のみをサポート •
トランザクションカットスルーにより ブロックチェーンデータを削減&プライバシーを向上 • 前提知識 ◦ Confidential Transaction https://goblockchain.network/2019/02/confidential-transaction/
2 Pedersen Commitment Confidential Transactionを導入して量を秘匿化 Commitment = rG + vH
r: ブラインドファクター、 v: コインの量 G, H:楕円曲線上の異なる生成点 • フルノードによる量の検証 {Outputのcommitmentの合計 + fee*H} - {Inputのcommitmentの合計} = 0 Output commitment range proof vが0〜2^64の範囲内であることを証明 Bitcoinのようなロックスクリプト( scriptPubkey)は存在しない。
3 コインの所有権の証明 Commitmentのブラインドファクター = 秘密鍵 Commitment = rG + vH
rの値はコインの受信者がランダムに決定する • InputのCommitment ◦ c1 = 38G + 2H ◦ c2 = 29G + 1H • OutputのCommitment ◦ c3 = 78G + 3H • {Outputのcommitmentの合計} - {InputのCommitmentの合計} = 0 ◦ c3 - {c1 + c2} = 78G + 3H - {38G + 2H + 29G + 1H} = 78G + 3H - {67G + 3H} = 11G != 0 超過値(Excess)が出る。 但し、Hの係数は0になっているため、超過値を秘密鍵として デジタル署名を作ることはできる。
4 コインの所有権の証明 Tx Inputs c1 = 38G + 2H c2
= 29G + 1H Outputs c3 = 78G + 3H Tx Kernel fee: 0H Excess: 11G Excess Sig: lock_height InputsとOutputsのCommitmentとfeeから Excess値を算出し、トランザクションカーネルにセット Excess値を秘密鍵としてトランザクションに署名 ※ トランザクションの署名鍵を知るにはトランザクションの全インプット、 アウトプットのブラインドファクターの知識が必要。
Input ②トランザクションの雛形を作成し、 インプットにコインのCommitmentをセット、 新しくブラインドファクターを選択しお釣り用の Commitmentをアウトプットにセットし、 Txとブラインドファクターの総計を受信者に送る。 5 トランザクションの作成フロー 送信者 受信者
①送金するコインの量(5コイン)に合意 Tx C1 = 15G + 3H C2 = 39G + 4H Output C3 = 78G + 1H 78 - (15 + 39) = 24 ※ 手数料=1コイン ③ 受信用にランダムなブラインドファクターを選択し、 Commitmentを作成。 C4 = 18G + 5H ④ 自身のコミットメントのブラインドファクターと 送信者から受け取ったブラインドファクターの総計から Excess値を計算。 24 + 18 = 42 ⑤ Excess値(42)を秘密鍵として、トランザクションの署名を 作成し、Excess値と署名をトランザクションカーネルにセットし、 ブロードキャスト ⑥フルノードはExcess = {C3 + C4 + fee*H} - {C1 + C2}か検証し、 Excess値の公開鍵に対して有効な署名があるか検証する。 ※ 厳密には各Commitmentのrange proofの検証も行う。
Input ②トランザクションの雛形を作成し、 インプットにコインの Commitmentをセット、 新しくブラインドファクターを選択しお釣り用の Commitmentをアウトプットにセットし、 署名に使うランダムな nonce ksを選択。 Txとブラインドファクターの総計と
ks*Gを受信者に送る。 6 トランザクションの作成フロー(Grin) 送信者 受信者 ①送金するコインの量(5コイン)に合意 Tx C1 = 15G + 3H C2 = 39G + 4H Output C3 = 78G + 1H 78G - (15G + 39G) = 24G ※ 手数料=1コイン ③ 受信用にランダムなブラインドファクターを選択し、 Commitmentを作成。 C4 = 18G + 5H ④ 自身のコミットメントのブラインドファクターと 送信者から受け取ったブラインドファクターの総計から Excess値を計算。 24G + 18G = 42G ⑤ 署名に使うランダムな nonce krを選択する。 署名に使用するnonceの点はR = ks*G + kr*G 署名対象のメッセージを M = fee | lock_heightとし、 署名用のチャレンジ e = SHA256(R| 18G + 24G | M) を計算し、 受信者のSchnorr署名 sr = kr + e*18 を計算し、 sr、18G、kr*Gを送信者に送る。 ⑥ 署名に使用するnonceの点を計算 R = ks*G + kr*G 署名用のチャレンジ e = SHA256(R| 18G + 24G | M) を計算し、 送信者側のSchnorr署名 ss = ks + e*24を計算。 署名を集約しトランザクションの署名を完成させる。 s = ss + sr = ks + kr + e*(24 + 18) (R, s)がトランザクションの署名。秘密鍵は Excess値(42) ※ Grinの場合は公開鍵を送る。 ks*G
7 Cut-through Tx1 C1 = 15G + 4H C2 =
39G + 2H Input Output C3 = 25G + 2H Tx2 C4 = 76G + 1H Input Output C5 = 91G + 1H C2 = 39G + 2H Tx3 C6 = 125G + 3H Input Output C3 = 25G + 2H C4 = 76G + 1H Excess: 49G Excess: 128G Excess: 24G Kernel Kernel Kernel
8 Cut-through Tx1 C1 = 15G + 4H C2 =
39G + 2H Input Output C3 = 25G + 2H Excess: 49G Tx2 C4 = 76G + 1H Input Output C5 = 91G + 1H C2 = 39G + 2H Tx3 C6 = 125G + 3H Input Output C3 = 25G + 2H C4 = 76G + 1H Excess: 128G Excess: 24G Kernel Kernel Kernel
9 Cut-through Tx C1 = 15G + 4H Input Output
Excess: 49G C5 = 91G + 1H C6 = 125G + 3H Excess: 128G Excess: 24G Kernel 使用済みのCommitmentは不要であるため 削除でき、ブロックチェーンのディスクサイズの 削減やプライバシー向上の効果がある。 Grinでは各Tx Kernelの署名 は集約されず、ブロック内のト ランザクションのTx Kernelは その数のまま残る。 Andrew Poelstraはこれらを 集約するsinking signatureを 発表しているが、一方 Scriptless Scriptがサポート できなくなることもあり、Grinは 集約型のSchnorr署名を採用 している。
10 まとめ • Mimblewimbleは何年も運用しても低コンピューティング デバイスでチェーンの検証を可能にする新しい ブロックチェーンの提案 • Confidential TransactionやトランザクションCut-through によってユーザーに強力なプライバシーを提供
• 現時点ではGrinとBEAMがサポート https://grin-tech.org/ https://www.beam.mw/ • 署名や範囲証明などをどこまでコンパクトにできるかが課題