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
Stanford Blockchain Conference 2019 レポート
Search
shigeyuki azuchi
March 14, 2019
Technology
1
360
Stanford Blockchain Conference 2019 レポート
ブロックチェーン開発者のためのGBECコミュニティイベントで発表したStanford Blockchain Conference 2019のレポートです。
shigeyuki azuchi
March 14, 2019
Tweet
Share
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
Replacement Cycling Attack
azuchi
0
12
Bitcoinのタイムロックの仕組み
azuchi
0
6
Inner Product Argument
azuchi
0
25
Codex32
azuchi
0
9
PSBT
azuchi
0
28
Trampoline Payment
azuchi
0
15
KZG Commitment
azuchi
0
99
Silent Payment
azuchi
0
62
FROST
azuchi
0
9
Other Decks in Technology
See All in Technology
Oracle Cloud Infrastructure:2024年4月度サービス・アップデート
oracle4engineer
PRO
1
190
元インフラエンジニアに成る / Human Resources to Human Relations
bobtani
4
890
FrontDoorとWebAppsを組み合わせた際のリダイレクト処理の注意点
kenichirokimura
1
480
開発パフォーマンスを最大化するための開発体制
ham0215
1
130
日本におけるデータエンジニアリングのこれまでとこれから
foursue
16
4.1k
ゼロから始めるVue.jsコミュニティ貢献 / first-vuejs-community-contribution-link-and-motivation
lmi
0
110
Next'24 事例セッションの紹介とクラウド資格を活用したキャリア形成について語りMuscle
yasumuusan
1
430
長期間TiDBを使ってきた話 @ 私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT / Experiences with TiDB Over Time
chibiegg
2
870
テストプロセスで大事にしていること #jasstnano
makky_tyuyan
0
160
Tableau事例紹介 / Tableau Case Study of Eureka
kazuya_araki_tokyo
1
180
オーナーシップを持つ領域を明確にする
konifar
13
3.1k
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.7k
Featured
See All Featured
Design by the Numbers
sachag
274
18k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
274
13k
The Pragmatic Product Professional
lauravandoore
25
5.8k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.6k
What the flash - Photography Introduction
edds
64
11k
We Have a Design System, Now What?
morganepeng
43
6.7k
Fantastic passwords and where to find them - at NoRuKo
philnash
37
2.5k
A Modern Web Designer's Workflow
chriscoyier
689
190k
Thoughts on Productivity
jonyablonski
58
3.8k
Principles of Awesome APIs and How to Build Them.
keavy
121
16k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
25
2.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
243
12k
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/