このセッションでは、技術的な観点からブロックチェーンの基本とその長所をスピーディーに学びます。また実演(デモ)を通してAzureへブロックチェーン サービスを展開する方法を習得できるほか、ブロックチェーンによるシステムと従来のリレーショナル データベースとの比較からそれぞれの特性を理解できます。セッションの最後には、実際のビジネスにおけるニーズを解決するために、どのようにブロックチェーンを適用すべきか(もしくは、すべきではないのか)について考察できるようになります。
Microsoft Ignite The Tour 2019 東京 BRK40003 (2019/12/6)
https://tokyo.myignitetour.techcommunity.microsoft.com/sessions/87449
Microsoft Ignite The Tour 2019 大阪 BRK40022 (2020/1/23)
https://osaka.myignitetour.techcommunity.microsoft.com/sessions/91086
57. Cordaのデータ構造
TX 1000:
C.pay($50)
State 100
IOU {
Lender: Alice
Borrower: Bob
Amount $100
}
Contract: C
State
インスタンスに相当
対応付けられたコントラクトC
TX
古いstatesをinputにし、新しいstatesをoutputに指定したもの
※古いstateはunspentでないといけない
State 100
IOU {
Amount $100
}
State 100
IOU {
Amount $50
}
あるノードのVault
State 100
…
State 100
…
State 100
…
State 100
…
State 101
…
Stateの最新状態
Vault
いわゆる台帳。Spent、unspentふくめ全てのstateを保持
58. TX 1000:
C.pay($50)
プロトコル (1): TXの提案
• Aliceが現状のstateをinput、更新後の
stateをoutputに含むTXを作成する
• このstateはAliceとBobの間で共有
• このstateにはコントラクトCが
関連付けられているとする
• TXのParticipantsをAlice, Bobとする
• AliceはTXに署名してBobのみに送信 Bob
台帳
Alice
台帳
State 100:v3
IOU {
From: Alice
To: Bob
Amount $100
}
Contract: C
Vault
State 100
v1
…
State 100
v2
…
State 100
v3
…
State 101
v1
…
State 101
v2
…
State 101:v2
Cash {
Owner: Alice
Amount $50
}
Contract: C
State 100:v4
IOU {
From: Alice
To: Bob
Amount $50
}
Contract: C
State 101:v3
Cash {
Owner: Bob
Amount $50
}
Contract: C
SigA
59. TX 1000:
C.pay($50)
プロトコル (2): TXの検証
• Bobは関連付けられたContractを使って、
提案された更新後stateが正しいことを検
証する
• UTXO制約も確認する
• 検証を通ったらBobはTXに署名をして
Aliceに送り返す
Bob
台帳
Alice
台帳
State 100:v3
IOU {
From: Alice
To: Bob
Amount $100
}
Contract: C
Vault
State 100
v1
…
State 100
v2
…
State 100
v3
…
State 101
v1
…
State 101
v2
…
State 101:v2
Cash {
Owner: Alice
Amount $50
}
Contract: C
State 100:v4
IOU {
From: Alice
To: Bob
Amount $50
}
Contract: C
State 101:v3
Cash {
Owner: Bob
Amount $50
}
Contract: C
SigA SigB
60. TX 1000:
C.pay($50)
プロトコル (3): Vault更新
• 両者の署名が得られたらTXが確定する
• AliceとBobはVaultを更新する
Bob
台帳
Alice
台帳
State 100:v3
IOU {
From: Alice
To: Bob
Amount $100
}
Contract: C
Vault
State 100
v1
…
State 100
v2
…
State 100
v3
…
State 101
v1
…
State 101
v2
…
State 101:v2
Cash {
Owner: Alice
Amount $50
}
Contract: C
State 100:v4
IOU {
From: Alice
To: Bob
Amount $50
}
Contract: C
State 101:v3
Cash {
Owner: Bob
Amount $50
}
Contract: C
SigA SigB
State 100
v4
…
State 101
v3
…
71. 参考文献 (論文)
• S. Grossman et al. (2017). Online
detection of effectively callback free
objects with applications to smart
contracts. POPL 2018, Article 48. DOI:
https://doi.org/10.1145/3158136
• 岩間, 立石, 齋藤, 天野, 吉濱 (2018). ブロッ
クチェーンにおけるチェーンコードの決定性
の解析. PPL ’18.
• 吉濱佐知子, 齋藤新 (2017). 分散台帳技術
におけるインテグリティとプライバシー保護.
CSS ’17.
• C. Cachin and M. Vukolić (2017).
Blockchain Consensus Protocols in the
Wild. http://arxiv.org/abs/1707.01873.
• J. Garay, A. Kiayias, N. Leonardos (2015).
The Bitcoin Backbone Protocol: Analysis
and Applications. EUROCRYPT ’15. DOI:
https://doi.org/10.1007/978-3-662-46803-
6_10. Latest version (2017) appears at
https://eprint.iacr.org/2014/765.pdf
• I. Eyal, E. Sirer (2014). Majority is Not
Enough: Bitcoin Mining is Vulnerable.
FC ’14. DOI: https://doi.org/10.1007/978-
3-662-45472-5_28
72. 参考文献 (論文) (2)
• S. Nakamoto (2008). Bitcoin: A Peer-to-
Peer Electronic Cash System.
http://bitcoin.org/bitcoin.pdf.
• S. Gilbert and N. Lynch (2002). Brewer's
conjecture and the feasibility of
consistent, available, partition-tolerant
web services. ACM SIGACT News 33
(2). DOI:
https://doi.org/10.1145/564585.564601
• M. Castro and B. Liskov (1999).
Practical Byzantine fault tolerance.
OSDI ’99.
• M. Fischer, N. Lynch and M. Paterson
(1985). Impossibility of distributed
consensus with one faulty process. J.
ACM 32 (2). DOI:
http://dx.doi.org/10.1145/3149.214121