This talk articulates 1) what is a blockchain 2) why it is interesting 3) talks through use-cases grounded in real world projects. 4) Highlights questions government leaders should ask before deciding to use a blockchain.
50. This LEDGER of Transactions
One SHARED LEDGER of Transactions
this is CHAIN of BLOCKS of Transaction
This is all maintained by a network of
commuters a, DISTRIBUTED LEDGER
57. * Do you need a shared, constant data store?
* Does more than one entity need to contribute
data? * (Do you need Auditing)
* Sensitive identifiers WILL NOT be written to
the data store?
* Data records, once written, are never
updated or deleted?
58. * Are the entities with write access having a
hard time who should be control of the data
store?
* Do you want a tamperproof log of all the writes
to the data store?
ONLY if the answers is YES to the above questions
You may have a useful Blockchain use case.
59. Lessons Learned from R&D Investments
Most Organizations Don’t Need A Blockchain
59
Do you need a shared,
consistent data store?
Does more than one
entity need to
contribute data?
Data records, once
written, are never
updated or deleted?
Sensitive identifiers
WILL NOT be written to
the data store?
Blockchains provide a historically
consistent data store. If you don’t need
that, you don’t need a Blockchain
CONSIDER: Email / Spreadsheets
Your data comes from a single entity.
Blockchains are typically used when data
comes from multiple entities.
CONSIDER: Database
CAVEAT: Auditing Use Cases
Blockchains do not allow modifications
of historical data; they are strongly
auditable
CONSIDER: Database
You should not write sensitive information
to a Blockchain that requires medium to
long term confidentiality, such as PII, even
if it is encrypted
CONSIDER: Encrypted Database
Are the entities with
write access having a
hard time deciding
who should be in
control of the data
store?
If there are no trust or control issues
over who runs the data store,
traditional database solutions should
suffice
CONSIDER: Managed Database
Do you want a
tamperproof log of all
writes to the data
store?
If you don’t need to audit what
happened and when it happened, you
don’t need a Blockchain
CONSIDER: Database
You may have a
useful Blockchain
use case
YES
YES
YES
YES
YES
YES
AUDITING
NO
NO
NO
NO
NO
NO
78. Verifiable Organizations Network
HolderIssuer Verifier
Issues
Claim
Decentralized Identifiers (DIDs)
Public Blockchain or other Decentralized Network
Signs
Claim
Countersigns
Claim
Wallet
Slide credit: Drummond Reed, Sovrin Foundation
BC GOVERNMENT BC BUSINESS
79. Verifiable Organizations Network
HolderIssuer Verifier
Issues
Claim
Decentralized Identifiers (DIDs)
Public Blockchain or other Decentralized Network
Signs
Claim
Countersigns
Claim
Verifies
Signatures
Wallet
Slide credit: Drummond Reed, Sovrin Foundation
BC GOVERNMENT BC BUSINESS CANADIAN GOVERNMENT
80. Verifiable Organizations Network
HolderIssuer Verifier
Issues
Claim
Presents
Claim
Decentralized Identifiers (DIDs)
Public Blockchain or other Decentralized Network
Signs
Claim
Countersigns
Claim
Verifies
Signatures
Wallet
Slide credit: Drummond Reed, Sovrin Foundation
BC GOVERNMENT BC BUSINESS CANADIAN GOVERNMENT
88. { “Key”: “Value” }
DID
Decentralized
Identifier
DID Document
JSON-LD document
describing the
entity identified by
the DID
Slide credit: Drummond Reed, Sovrin Foundation
89. 1. DID (for self-description)
2. Set of public keys (for verification)
3. Set of auth protocols (for authentication)
4. Set of service endpoints (for interaction)
5. Timestamp (for audit history)
6. Signature (for integrity)
89
The standard elements of a DID doc
Slide credit: Drummond Reed, Sovrin Foundation
90. 1. DID (for self-description)
2. Set of public keys (for verification)
3. Set of auth protocols (for authentication)
4. Set of service endpoints (for interaction)
5. Timestamp (for audit history)
6. Signature (for integrity)
90
The standard elements of a DID doc
Slide credit: Drummond Reed, Sovrin Foundation
91. 1. DID (for self-description)
2. Set of public keys (for verification)
3. Set of auth protocols (for authentication)
4. Set of service endpoints (for interaction)
5. Timestamp (for audit history)
6. Signature (for integrity)
91
The standard elements of a DID doc
Slide credit: Drummond Reed, Sovrin Foundation
92. 1. DID (for self-description)
2. Set of public keys (for verification)
3. Set of auth protocols (for authentication)
4. Set of service endpoints (for interaction)
5. Timestamp (for audit history)
6. Signature (for integrity)
92
The standard elements of a DID doc
Slide credit: Drummond Reed, Sovrin Foundation
93. 1. DID (for self-description)
2. Set of public keys (for verification)
3. Set of auth protocols (for authentication)
4. Set of service endpoints (for interaction)
5. Timestamp (for audit history)
6. Signature (for integrity)
93
The standard elements of a DID doc
Slide credit: Drummond Reed, Sovrin Foundation
98. HolderIssuer Verifier
Issues
Claim
Decentralized Identifiers (DIDs)
Public Blockchain or other Decentralized Network
Signs
Claim
Countersigns
Claim
Wallet
Slide credit: Drummond Reed, Sovrin Foundation
CREDIT UNION CU MEMBER
99. HolderIssuer Verifier
Issues
Claim
Decentralized Identifiers (DIDs)
Public Blockchain or other Decentralized Network
Signs
Claim
Countersigns
Claim
Verifies
Signatures
Wallet
Slide credit: Drummond Reed, Sovrin Foundation
CREDIT UNION CU MEMBER 2nd CREDIT UNION
100. HolderIssuer Verifier
Issues
Claim
Presents
Claim
Decentralized Identifiers (DIDs)
Public Blockchain or other Decentralized Network
Signs
Claim
Countersigns
Claim
Verifies
Signatures
Wallet
Slide credit: Drummond Reed, Sovrin Foundation
CREDIT UNION CU MEMBER 2nd CREDIT UNION
107. The Amply project, supported by UNICEF and
Innovation Edge, built a mobile app using the ixo
protocol to track attendance in pre-schools in
South Africa.
Combining mobile and blockchain technology to
increase impact and accountability of public
services and generate real-time data.
109. BlockChain and Land Rights?
Blockchain and Property in 2018:
At the End of the Beginning
110. Intro: Why Blockchain
Makes Sense for Real Estate
• The technology is decentralized, fault-tolerant, and tamper-resistant; offering
security and resiliency.
• Blockchain is disruptive for land governance, it may promote property
rights formalization, registry modernization, and the collection/analysis of
data.
• Blockchain can generate increased efficiency and lower transaction
costs in the global real estate sector.
• The technology allows for improved liquidity of property, financial inclusion,
and increased foreign investment.
111. Paper Overview
1. FPR’s seven prerequisites for blockchain
introduction into a land registry.
2. Conceptual framework: Eight levels of integration
from the simple to more radical.
3. Five topics on the future interaction of blockchain
and land, from title insurance to regulation.
4. Six case studies of companies active in the space.
112. Different Blockchain Flavors
Bitcoin,
Ethereum, IOTA,
Veres One
Permissionless Permissioned
Public
Private
Validation
Access
Hyperledger Sawtooth*
Sovrin,
IPDB
Hyperledger (Fabric,
Sawtooth, Iroha),
R3 Corda,
CU Ledger* in permissionless mode
Slide credit: Drummond Reed, Sovrin Foundation
114. Does my use case involved a database?
Will there be numerous users updating my database?
Do these users need to trust each other?
Are there problems caused by the use of central/third
party entity?
Do transactions depend on/interact with each other?
I should be using a blockchain!