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
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
Hyper Tree
azuchi
0
18
FORS
azuchi
0
29
クラスターmempool
azuchi
0
42
W-OTS+
azuchi
0
46
Shorのアルゴリズム
azuchi
0
69
DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
azuchi
0
54
Fiat-Shamir変換と注意点
azuchi
0
250
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
66
BIP-374 離散対数の等価性証明
azuchi
0
82
Other Decks in Technology
See All in Technology
Omarchy Quattro の日本語設定周り
simosako
2
110
Adaptive Warehouse を今すぐ導入すべき理由と迷ったときの判断基準
__allllllllez__
0
130
AI時代におけるプロダクト横断勉強会の設計
zozotech
PRO
0
170
TinyGo 開発サイクルを高速化する:Go で作るエミュレータ入門
zozotech
PRO
1
130
WAF 運用改善の承認サイクル/SRE_BizReach_MIXI_1
visional_engineering_and_design
2
390
AIで開発は速くなったのに、なぜ現場は楽にならないのか 〜あなたの組織のボトルネックを突き止めるワークショップ〜
jacopen
1
300
Tab5をRubyで動くパソコンにする
kishima
2
280
2026-09-04 SRE Tech Talk #15 怠惰なTerraform / Lazy Terraform
masasuzu
0
230
KPIだけでは評価できないプロダクトが考えるべき Evalsという第二の評価系 / Beyond KPIs: Evals as a Second Evaluation Framework for Products #PdEConf
aki_iinuma
4
3.8k
例外の正しい扱い方 そのエラー try-catchして大丈夫?
jinwatanabe
3
410
AI時代のAPI品質を支えるガードレール / API Guardrails for API quality in the AI era
yokawasa
1
190
作品が生態系になった ─ Mini Tokyo 3D から世界へ
nagix
0
140
Featured
See All Featured
Between Models and Reality
mayunak
4
450
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
450
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
56
3.5k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Visual Storytelling: How to be a Superhuman Communicator
reverentgeek
2
650
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
230
A better future with KSS
kneath
240
18k
Fireside Chat
paigeccino
42
4k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
410
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
410
Heart Work Chapter 1 - Part 1
lfama
PRO
8
36k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.8k
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/