Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Mimblewimble
Search
shigeyuki azuchi
March 29, 2019
Technology
65
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Mimblewimble
GBEC動画解説コンテンツのスライドです。
https://goblockchain.network/2019/03/mimblewimble/
shigeyuki azuchi
March 29, 2019
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
SLH-DSA (SPHINCS+)
azuchi
0
19
Hyper Tree
azuchi
0
22
FORS
azuchi
0
34
クラスターmempool
azuchi
0
44
W-OTS+
azuchi
0
50
Shorのアルゴリズム
azuchi
0
72
DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
azuchi
0
58
Fiat-Shamir変換と注意点
azuchi
0
260
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
71
Other Decks in Technology
See All in Technology
[JAWS-UG彩の国埼玉#12]そろそろ準備する?re:Invent2026をやさしく解説 / reinvent2026-sainokuni
sh_fk2
1
340
AI × アーキテクト 第1・2章|生成AIの課題とアーキテクトの素養
daidaidai
0
170
継続的なAIコスト最適化
bgpat
1
340
Local CI × GitHub Actions
gogutan
2
190
日本語に強いオープンな大規模言語モデル「LLM-jp」
odashi
4
1.1k
夫婦で子育てするための育児標準化
codmoninc
PRO
0
330
Claude の新機能を、 出た日に触って社内に届けるまで
rfdnxbro
1
170
AI導入は済んだ。次は統制を作り替える番だ_AI×開発組織 Summit 2026
techtekt
PRO
0
210
今さら理解するウェブフォントver.2026
takanorip
3
770
パスキーの自動テストはどこまでいけるのか
teamlab
PRO
0
200
1つのリクエストを追って理解する - llm-dのP/D分離
akhino
1
160
コンテナ運用におけるネットワーク・コンテナコストの削減方法/How to Reduce Network and Container Costs in Container Operations
masakiokuda
1
150
Featured
See All Featured
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
640
StorybookのUI Testing Handbookを読んだ
zakiyama
31
7k
Darren the Foodie - Storyboard
khoart
PRO
4
4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
220
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
360
Crafting Experiences
bethany
1
380
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
300
Building Applications with DynamoDB
mza
96
7.2k
Odyssey Design
rkendrick25
PRO
2
870
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
340
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
930
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/ • 署名や範囲証明などをどこまでコンパクトにできるかが課題