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
64
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
12
Hyper Tree
azuchi
0
18
FORS
azuchi
0
31
クラスターmempool
azuchi
0
43
W-OTS+
azuchi
0
50
Shorのアルゴリズム
azuchi
0
71
DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
azuchi
0
55
Fiat-Shamir変換と注意点
azuchi
0
260
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
69
Other Decks in Technology
See All in Technology
Deployment の 先にある AI Agent 基盤 - kagent vNext、Agent Substrate、Hermes から読み解く Agent Runtime の現在地 / k8s-matsuri-2-ai-agent-platform-amsy810
masayaaoyama
4
700
事業課題から技術的負債に向き合う
sansantech
PRO
2
2.3k
C#コードの結合を可視化する Roslyn解析による設計改善と リファクタリング判断
dora56
0
350
Railsのように考える: See through the Master
snoozer05
PRO
5
1.3k
Cloudflare Workers 向けアプリを C# で構築する ~WASM Native AOT への道~
nenonaninu
1
1k
Oracle Cloud Infrastructure(OCI):Onboarding Session(はじめてのOCI/Oracle Supportご利⽤ガイド)
oracle4engineer
PRO
2
20k
あけおめLINE 傾向とその対策
nasa9084
0
270
30座EKS, 180次升級淬煉的EKS Upgrade Skill 的歷程
eric8230
0
210
技術的負債から考える、AI時代のエンジニアリング投資 — ビズリーチの技術的負債と向き合った経験から、変更し続けられるソフトウェアを考える/ technical-debt-con2026
visional_engineering_and_design
4
3.6k
その Lambda、8分で 管理者権限まで奪われます
k1nakayama
7
3.6k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
16
120k
JSONataとAWS Step Functionsで目指すRuntimelessな世界
mu7889yoon
0
430
Featured
See All Featured
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
1
410
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
510
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
120
120k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.3k
How GitHub (no longer) Works
holman
316
150k
RailsConf 2023
tenderlove
30
1.6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
470
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
830
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
35
2.8k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
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/ • 署名や範囲証明などをどこまでコンパクトにできるかが課題