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
Stanford Blockchain Conference 2019 レポート
Search
shigeyuki azuchi
March 14, 2019
Technology
440
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Stanford Blockchain Conference 2019 レポート
ブロックチェーン開発者のためのGBECコミュニティイベントで発表したStanford Blockchain Conference 2019のレポートです。
shigeyuki azuchi
March 14, 2019
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
SLH-DSA (SPHINCS+)
azuchi
0
10
Hyper Tree
azuchi
0
18
FORS
azuchi
0
30
クラスターmempool
azuchi
0
43
W-OTS+
azuchi
0
49
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
GoのInterface内部構造から学ぶ!最高パフォーマンスを出すコード設計
yappli_developers
0
150
Claude Code本って、 読む必要あるの?
oikon48
2
470
beyond jj: config & tools ecosystem
indirect
0
3.6k
絵ではじめるKubernetesセキュリティ
aoi1
4
670
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
2
540
AgentCore Runtime上にAgentic Coding基盤を構築・展開する際の設計ポイントと限界点 / Design considerations and limitations when building an agentic coding platform on AgentCore Runtime
har1101
4
290
アクセスキーこわい やめかたと漏らさない工夫
sassssan68
1
400
synctest時代のhttptest Go 1.27で変わるHTTPサーバテストの裏側 / go conference2026 synctest and httptest
budougumi0617
1
3k
目の前の楽しいが人生を変える - コミュニティの螺旋の歩き方と楽しむコツ / change your life
soudai
PRO
5
640
現場で役立つ技術負債の効果的な返済方法
masuda220
PRO
9
4.5k
AIエージェントの権限管理 3: Agentic RAG の Fine grained access control 編
ren8k
0
110
事業課題から技術的負債に向き合う
sansantech
PRO
2
2k
Featured
See All Featured
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
430
Mobile First: as difficult as doing things right
swwweet
225
10k
Technical Leadership for Architectural Decision Making
baasie
3
570
Everyday Curiosity
cassininazir
0
320
What's in a price? How to price your products and services
michaelherold
247
13k
Test your architecture with Archunit
thirion
2
2.4k
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
410
How GitHub (no longer) Works
holman
316
150k
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.6k
Git: the NoSQL Database
bkeepers
PRO
432
67k
Statistics for Hackers
jakevdp
799
230k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
360
Transcript
Stanford Blockchain Conference 2019 レポート 2019.03.14 Shigeyuki Azuchi ブロックチェーン開発者のためのGBECコミュニティイベント
1 Stanford Blockchain Conference 2017年から毎年開催されているスタンフォード大学主催の ブロックチェーンカンファレンス • 2019.01.30 - 2019.02.01
• 参加者は去年から倍増して900人 • トータル34セッション • プライバシー関連やzk-STARKs系の発表が多め • 1番の人気セッションはVitalikのEthereum 2.0 • 来年も開催予定!
2 Building Mimblewimble/Grin 2019年1月に稼働したMimblewimbleをサポートする Blockchain • Mimblewimble以外にも多くの構成要素が Schnorr署名 Bulletproofs (range
proof) Switch Commitment Cuckoo Cycle Dandelion++ Time-lock Contract Flyclient Atomic Swap Scriptless Script RSA Accumulator Vaults Covenants MMR
3 Building Mimblewimble/Grin 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 Building Mimblewimble/Grin 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値を秘密鍵としてトランザクションに署名 ※ トランザクションの署名鍵を知るにはトランザクションの全インプット、 アウトプットのブラインドファクターの知識が必要。
5 Building Mimblewimble/Grin 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 Tx Input Output Kernel C1 = 15G + 4H C5 = 91G + 1H C6 = 125G + 3H Excess: 49G Excess: 128G Excess: 24G Cut-through
6 Building Mimblewimble/Grin Dandelion++ トランザクションのブロードキャストの前に約10ホップほどトランザクションを 中継するフェーズを設けることでトランザクションソースを難読化 Stemフェーズ中に トランザクションカットスルーを 行うことで、よりプライバシーの 向上に。
7 Building Mimblewimble/Grin Switch Commitment 離散対数仮定が崩れた際にConfidential Transactionを採用するチェーンの 安全性を守るためのコミットメント Pedersen Commitment
= rG + vH H = xGとなるxが分かるとコインを無限生成できるようになる。 (r, vをr’ = r + x(v - v’)となるr’, v’に置換する) Elgamal Commitment = (rG + vH, rH) Elgamal Commitmentの前半部はPedersen Commitmentなので、 通常はPedersen Commitmentのrange proofをチェックし、 脅威が現実的になったらElgamal Commitment用のrange proofに切り替え
ごく僅かなデータでUTXOの管理が可能 • Setup ◦ 秘密の素数p,qから、N = p * qを計算 ◦
H()任意の要素を素数にマッピングするハッシュ関数 ◦ アキュムレータを初期化A0 = g ∈ Zn • アキュムレータへの要素xの追加 • アキュムレータから要素xの削除 • アキュムレータAに要素xが存在するinclusion proof 8 Accumulators for Blockchains inclusion proofの検証は
9 QuisQuis 既存の匿名通貨 • Dash 同一金種のコインを1つのトランザクションでミキシング ◦ 集中型Tumblerはプライバシーの課題 ◦ 分散型Tumblerはマッチングコスト高
• Monero 送信者がチェーン上から無作為にダミー送金元をピックアップ ◦ どのUTXOが使われたのか分からないのでUTXOセットが成長 • Zcash ゼロ知識証明プロトコルの1つzk-SNARKsを使って送金元、送信先、量を秘匿 ◦ Trusted Setupが必要
10 QuisQuis Updatable Public key Tx Inputs Outputs Pubkey B
Receiver Pubkey Sender Pubkey Updated Pubkey B’ Gen Update Verify Public Key Private Key nonce r Updated Public Key
11 HTLCs Considered Harmful. HTLCの問題点を解消するための代替案 • HTLCを使ったCross-chain Atomic Swap HTLC(Hashed
Time-Locked Contracts)は ハッシュのプリイメージ(シークレット)とコインを交換する タイムロック付きのコントラクト アリスはBitcoinを以下のアンロック条件のスクリプトに送る。 • H(S)のプリイメージ=シークレットSが分かればボブは BTCを入手できる。 • 10日経過したらアリスはBTCを入手できる。 Secret S H(S) ボブはLTCを以下のアンロック条件のコントラクトに送る。 • H(S)のプリイメージ=シークレットSが 分かればアリスはLTCを入手できる。 • 5日経過したらボブはLTCを入手できる。 BTC/LTCを交換
12 HTLCs Considered Harmful. HTLCsの問題点 • Free Option Probrem アリスは、有効期限まで待って、LTCのボラティリティに
よっては交換と取りやめることができる。 アリスはBitcoinを以下のアンロック条件のスクリプトに送る。 • H(S)のプリイメージ=シークレットSが分かればボブは BTCを入手できる。 • 10日経過したらアリスはBTCを入手できる。 ボブはLTCを以下のアンロック条件のコントラクトに送る。 • H(S)のプリイメージ=シークレットSが 分かればアリスはLTCを入手できる。 • 5日経過したらボブはLTCを入手できる。 BTC/LTCを交換 Secret S H(S)
13 HTLCs Considered Harmful. • Griefing Probrem 1 BTCをHTLCにロック 1
BTCをHTLCにロック 1 BTCをHTLCにロック 1 BTCを受け取り 1 BTCを受け取り 1 BTCを受け取り Stuck 受信者が受け取りのアクションを返さないと 各HTLCはタイムロックが経過するまでスタックする。 その間、各HTLCの資金はロックされ流動性も無くなる。 Payment Channel Networkの攻撃ベクトルになる恐れも。
Balance 3 BTC 6 BTC Packetized Payments 1つの大きな送金の代わりに送金を分割する Balance 4.98
BTC 5.02 BTC 14 HTLCs Considered Harmful. Owner Balance アリス 4 BTC ボブ 5 BTC Owner Balance アリス 4.99 BTC ボブ 5.01 BTC ・・・ Balance 14 LTC 10 LTC Balance 4.2 LTC 19.8 LTC Owner Balance アリス 4 LTC ボブ 20 LTC Owner Balance アリス 4.1 LTC ボブ 19.9 LTC ・・・ 0.1 LTCずつ送金 0.01 BTCずつ送金 • 送金を小さく分割し交互に送金 • 許容可能な損失の1回分の金額に • 相手が送金を途中で止めたらチャネルをクローズ • Atomic SwapではなくなるがHTLCの問題を解消
15 その他にも • Bulletproofsを効率的に実装するためのDecafeとRistretto • Cloak:Bulletproofsを使ったConfidential Assets • コントラクトの形式証明 •
Miniscripts • プライバシー特性のあるPoSプロトコル • ERC 20, 721といったトークン取引のプライバシーを確保す る分散プライベート計算スキーム • CBC Casper • Ethereum 2.0 Beacon chain PoS→シャーディング→State Execution→STARKs • 閾値署名のための効率的な分散鍵生成 • 分散型暗号通貨ウォレットのための最小設計
16 Reference 各セッションの内容はYoutubeで! • Schedule https://cyber.stanford.edu/sbc19 • Video ◦ Day1
https://www.youtube.com/watch?v=XckwEw8FyEA ◦ Day2 https://www.youtube.com/watch?v=sQOfnsW6PTY ◦ Day3 https://www.youtube.com/watch?v=U5fEvfAFs_o • Transcript http://diyhpl.us/wiki/transcripts/stanford-blockchain-conference/2019/ (一部のみ)
17 続きは https://goblockchain.network/