$30 off During Our Annual Pro Sale. View Details »
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
410
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
10
DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
azuchi
0
10
Fiat-Shamir変換と注意点
azuchi
0
98
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
20
BIP-374 離散対数の等価性証明
azuchi
0
36
BIP-353 DNS Payment Instructions
azuchi
0
57
OP_CAT and Schnorr Trick
azuchi
0
54
Pay to Anchorと1P1Cリレー
azuchi
0
49
プロアクティブ秘密分散法
azuchi
0
70
Other Decks in Technology
See All in Technology
まだ間に合う! Agentic AI on AWSの現在地をやさしく一挙おさらい
minorun365
17
2.8k
Snowflake導入から1年、LayerXのデータ活用の現在 / One Year into Snowflake: How LayerX Uses Data Today
civitaspo
0
2.4k
"人"が頑張るAI駆動開発
yokomachi
1
570
AI駆動開発の実践とその未来
eltociear
2
500
20251218_AIを活用した開発生産性向上の全社的な取り組みの進め方について / How to proceed with company-wide initiatives to improve development productivity using AI
yayoi_dd
0
670
オープンソースKeycloakのMCP認可サーバの仕様の対応状況 / 20251219 OpenID BizDay #18 LT Keycloak
oidfj
0
180
モダンデータスタックの理想と現実の間で~1.3億人Vポイントデータ基盤の現在地とこれから~
taromatsui_cccmkhd
2
270
さくらのクラウド開発ふりかえり2025
kazeburo
2
1.2k
半年で、AIゼロ知識から AI中心開発組織の変革担当に至るまで
rfdnxbro
0
140
100以上の新規コネクタ提供を可能にしたアーキテクチャ
ooyukioo
0
260
フィッシュボウルのやり方 / How to do a fishbowl
pauli
2
390
Amazon Bedrock Knowledge Bases × メタデータ活用で実現する検証可能な RAG 設計
tomoaki25
6
2.4k
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
46
7.8k
The agentic SEO stack - context over prompts
schlessera
0
560
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
130
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
750
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
89
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
45
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
2
2.8k
HDC tutorial
michielstock
0
280
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.8k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
580
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
1
410
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/