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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
shigeyuki azuchi
March 14, 2019
Technology
1
420
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
Shorのアルゴリズム
azuchi
0
21
DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
azuchi
0
17
Fiat-Shamir変換と注意点
azuchi
0
130
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
24
BIP-374 離散対数の等価性証明
azuchi
0
45
BIP-353 DNS Payment Instructions
azuchi
0
63
OP_CAT and Schnorr Trick
azuchi
0
61
Pay to Anchorと1P1Cリレー
azuchi
0
51
プロアクティブ秘密分散法
azuchi
0
77
Other Decks in Technology
See All in Technology
AIエージェントに必要なのはデータではなく文脈だった/ai-agent-context-graph-mybest
jonnojun
1
250
usermode linux without MMU - fosdem2026 kernel devroom
thehajime
0
240
Exadata Fleet Update
oracle4engineer
PRO
0
1.1k
OWASP Top 10:2025 リリースと 少しの日本語化にまつわる裏話
okdt
PRO
3
850
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
10k
Bedrock PolicyでAmazon Bedrock Guardrails利用を強制してみた
yuu551
0
260
データの整合性を保ちたいだけなんだ
shoheimitani
8
3.2k
SREが向き合う大規模リアーキテクチャ 〜信頼性とアジリティの両立〜
zepprix
0
480
登壇駆動学習のすすめ — CfPのネタの見つけ方と書くときに意識していること
bicstone
3
130
日本の85%が使う公共SaaSは、どう育ったのか
taketakekaho
1
240
【Ubie】AIを活用した広告アセット「爆速」生成事例 | AI_Ops_Community_Vol.2
yoshiki_0316
1
120
ブロックテーマ、WordPress でウェブサイトをつくるということ / 2026.02.07 Gifu WordPress Meetup
torounit
0
200
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.4k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
390
Game over? The fight for quality and originality in the time of robots
wayneb77
1
120
Producing Creativity
orderedlist
PRO
348
40k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
110
Writing Fast Ruby
sferik
630
62k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
79
The Cult of Friendly URLs
andyhume
79
6.8k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
240
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.3k
Paper Plane (Part 1)
katiecoart
PRO
0
4.3k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
52
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/