Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Untangling BlockChainSystems vis-à-vis Data
Systems
Beng Chin OOI 黄铭钧www.comp.nus.edu.sg/~ooibc
Congruence of ABCD
2
BigData/DBMS
Objectives:1. Transparency2. Accountability3. Auditability4. Governance5. Security6. …
Analytics/DataSc
Outline
• BlockChain 101• BlockChain vs Data System• Performance Benchmarking• Speeding Up
• ForkBase• Trusted hardware
• MediLOT healthcare protocol• Conclusions
Acknowledgement: many diagrams are owned by internet users which we use only for illustration purposes
A. Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi, K.-L. Tan: BLOCKBENCH: A Framework for Analysing Private Blockchains. ACM SIGMOD 2017
A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, J. Wang: Untangling Blockchain: A Data Processing View of Blockchain Systems. 20p. IEEE Trans. Knowledge and Data Engineering, July 2018
S. Wang, T. T. A . Dinh, Q. Lin, Z. Xie, M. Zhang, Q. Cai, G. Chen, W. Fu, B.C. Ooi, P. Ruan: ForkBase: An Efficient Storage Engine for Blockchain and Forkable Applications. VLDB 2018
H. Dang, A. Dinh, E.-C. Chang, B. C. Ooi: Chain of Trust: Can Trusted Hardware Help Scaling Blockchains? arXiv, 2 April 2018
Backgrounds
Bitcoin & the Blockchain
• No central bank• Transferring coins through
trustless P2P network• Hit 19000 USD per Bitcoin
Cryptocurrency
“Satoshi Nakamoto” 2009
• Blockchain• Distributed shared ledger• Cryptograhy (SHA-256, PKI)• Consensus model• Smart contracts
Technology
5
Blockchain 101
● Definition○ Distributed, append-only ledger storing ordered transactions○ Blocks are chained together using cryptographic hash pointers○ Shared and maintained by mutually distrusting nodes
● Blockchain Consensus Protocol○ Mutually distrusting nodes periodically agree on a new block to be
appended to the blockchain
Block 4Block 3Block 2Block 1
H(Block3)
Tx1 Tx2Tx3
…
The Blockchain Consensus Problem
● Node Identities:○ Permissionless: No inherent ID or PKI○ Permissioned: Nodes and their messages can be authenticated
● Consensus protocols:○ Lottery-based protocol: suitable for permissionless BC, support large
number of nodes○ Byzantine Fault Tolerant (BFT) protocol: suitable for permissioned BC,
attain high throughput
● Properties:○ Safety○ Liveness
4 Key Concepts of BlockChain
Distributed shared ledger Cryptography
Consensus Smart contracts
Append-only distributed
system of record shared
across business
network
Ensuring appropriate
visibility; transactions are
secure, authenticated
& verifiable
All parties agree to
network verified
transaction
Business terms
embedded in transaction
database & executed
with transactions
9
Distributed Shared Ledger
• Group of replicated logs• Transactions packed in blocks• All nodes hold the same log• Parties identified by public keys
10
Consensus
Consensus
C Vukolić, Marko. "The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication."
Voting-basedComputation-based
• No single point of failure• Byzantine fault tolerance
12
Smart Contracts
• A complex set of software codes with components designed to automate execution and settlement, is the application layer that makes much of the benefits of blockchains.
• Thinks stored procedures operating on blockchain data
• Execution (input, output) agreed by all parties. Source: Everest Group14
Examples
Bitcoin Ethereum Hyperledger
Membership Open for all Open for all Authenticated
State Coin values Accounts (with value and key/value storage)
Key/value storage space
Transactions Delete, create coins
Transfer value, update account storage
Update key/value
Current Practice
Party D’s Records Bank Records
Auditor Records
Party A’s Records
API-integrations
Hack
Ledger
Party B’s Records
Ledger
Ledger
Ledger
Party C’s Records
Ledger
Ledger
Information & asset exchange in business networks – Separate ledgers
Inefficient, expensive, error sensitive and vulnerable
Without Blockchain
16
Transformation
Information & asset exchange in business networks – Shared ledger
Consistency, efficiency, security, immutability, provenance, resilience…
Party D’s Records Bank records
Party C’s Records Auditor records
Party B Records
Party A’s Records
Ledger
Ledger
Ledger
LedgerLedger
Ledger
With Blockchain
17
Blockchain: Looking beyond Hype
Source: Everest Group
18
BFSI: Banking, Financial Services, Insurance
Blockchain in the Wild
Real world example #1. R3CEV financial consortium
• A consortium of more than 100 the world biggest financial institutions.
• Research and develop blockchain system in the financial services.
• Develop and test smart-contract templates that simplify legal documentation.
19
Blockchain in the Wild
Real world example #2. Linux Foundation Hyperledger Project
• A cross-industry collaborative project started in December 2015 by the Linux Foundation.
• Focus on distributed ledger to support global business transactions, including major technological, financial, and supply chain companies.
20
Values of BlockChains
Reduction of costs and complexity Shared trusted transactions
Resilience Secure Auditability
Reduction of errors
Transparency and Consensus Reduced Complexity and TransparencyMore Direct Dealing
Cryptography, Replication, ImmutabilityP2P and Replication Immutability
With increasing data and transaction volume, can BlockChain handle the load?
Database terms• ACID properties
• Transactions• Persistency• Logging (Roll-back)
• Efficiency• Concurrency control• Group commit• Buffering• Prefetching• Indexing• Parallel/Distributed processing
• Query processing • Ad hoc queries formulated based on primitive operators• Stored procedures
• Storage engine• Compression• Columnar/row-based storage• …
23
OverviewBlockChain DBMS
Goal Disintermediation to avoid the central trust
Modularization for efficient data management
Architecture Decentralized across multiple nodes with different administrators
• C/S Architecture with a single node
• Distributed nodes under a single administrator
Node Relationship
Not Inter-trustable Cooperative but with checks
and balances
• Inter-trustable• Cooperative
Focused Attributes(From High Priority to Low)
1. Fault Tolerance2. Scalability3. Performance
1. Performance• Throughput• Latency
2. Scalability3. Fault tolerance
Distributed SystemsBlockChain DBMS
Failure Model Byzantine Crash-stop
Network Model Eventual Synchronous • Eventual Synchronous• Synchronous
Consensus Byzantine Fault Tolerance (BFT)
PBFT (Safety over Liveness) PoX-variant (Liveness over
Safety)
• Crash Fault Tolerance (CFT)• Leader-based○ Raft ○ Paxos○ Viewstamped
• Leader-less○ Quorum
Consistency Level Strong Consistency (PBFT) Eventual Consistency PoX-
variant)
• Strong Consistency• Weak Consistency○ Bounded Staleness○ Consistent Prefix○ Eventual Consistency
CAP Spectrum
● 2 out of 3 Properties○ Consistency○ Availability○ Partition-Tolerance PoX-based
Blockchain
PBFT-basedBlockchain
Storage/database engineBlockChain DBMS
Data Models Txn-based Account-based KV-based
• Relational • NoSQL• Document (JSON, XML)• Graph
Query Language
N.A. • SQL (Relational)• Cipher (Graph)• XPath (Document)
Operations Validate (Read)○ On Single Node
Append○ On Multiple Nodes
• CRUD○ Create○ Retrieve○ Update○ Delete
• Managed on multiple nodes
Index StructuresBlockChain DBMS
Data Structure (Memtable)
Merkle Patricia Trie(Ethereum)
Bucket Tree (Hyperledger)
• LSMTree with Log-structured SSTables
• B-trees
Concern Efficient Retrieval Append-Optimized Write
○ Deduplication Security
○ Tamper evidence○ Easy Validation
• Efficient Retrieval• Update/Delete Optimized Write
Storage LayoutBlockChain DBMS
Replication Full, Leaderless Replication
• Master-slave Replication• Multi-leader Replication• Leaderless Replication (Dynamo
style)
Sharding No Sharding (Majority) Transaction Sharding
(Zilliqa) State Sharding
(Omniledger)
• Key Range Sharding• Hash Range Sharding
Requestor Router
Broadcast (Bitcoin) Responsibility of Client
(Omniledger)
• Central Gateway• Thread Pool
Txn Property (ACID)BlockChain DBMS
Atomicity Involve Single Node Rollback Scheme (Redo logs,
Buffer)
• Involve Multiple Nodes• Two Phase Commit (2PC)
Consistency Specified by Protocol, e.g NO double spending on a
single input …
Jointly Guaranteed by o DBMS developer o DBA operator
Isolation Serializability (Sequential execution under a single thread)
• Read Uncommited• Read Commited• Snapshot Isolation• Serializability (Two Phase Locking)
Durability Full Replication Ledger Tamper-evidence
• Write Ahead Logs (WAL) on memtable
• Persistance Layer
Ethereum Transaction
Receipts, logs = []
For each txn in block:
stateDB.prepare(txn)
receipt, log, err = ApplyTxn(txn)
receipts.append(receipt)
logs.append(log)
stateDB.finalize(txn)
Consensus.validate(ledger, block, receipts, logs)
Block from Consensus Layer(Either mined or received)
Serial execution
Ethereum (cont’d)
Func ApplyTxn(txn):
validate signature of the txn sender’s
deduct ethers for gas from sender’s account
if ContractCreation:
contractAddr = CreateContractAdd()
log, receipt, err = evm.CreateContract(txn.Data, contractAddr)
else:
code = stateDB.GetCode(txn.codeHash)
log, receipt, err = evm.CallContract(txn.Data, code)
Refund ethers for unused gas
return log, receipt, err
Ethereum (cont’d)
Func EVM.CallContract(code, input) {
CHECK for call stack depth
CHECK for sufficient fund at sender account
snapshot = stateDB.getSnapshot()
gas, err = interpreter.run(evm, code, input)
if err: stateDB.revert(snapshot)
}
Snapshot is backed Up for rollback purposes
StateDB (Trie)• Caching Mechanism
• Read
• Update
FullNode (a)
HashNode (c)HashNode (b)
FullNode(a)
LeafNode ( c )HashNode(b)
{Dirty: false,Age: 0, Hash: <hash>}
FullNode (a)
HashNode (b) LeafNode ( c )
FullNode (a)
FullNode (b) LeafNode ( c )
NewChildNode (d)
{Dirty: true,Age: 0, Hash: <hash>}
{Dirty: true,Age: 0, Hash: <old-hash>}
{Dirty: true,Age: 1, Hash: <hash>}
1 2
3 4
StateDB (Trie)• Commit FullNode (a)
FullNode (b) LeafNode ( c )
NewChildNode (d){Dirty: true,
Age: 0, Hash: <hash>}
{Dirty: true,Age: 0, Hash: <old-hash>}
{Dirty: true,Age: 1, Hash: <hash>}
FullNode (a)
FullNode (b) HashNode ( c )
ChildNode (d){Dirty: false,
Age: 1, Hash: <hash>}
{Dirty: false,Age: 1, Hash: <new-hash>} Unload to Persistance (LevelDB)
Dump new Node to Persistance (LevelDB)
Return Hash
5
6
StateDB (Trie)
• Snapshot Maintenance• A list of Undo Logs
• Commit• Clear unused logs
• Rollback• Sequential perform undo logs
UnsetState
UnsetBalance
Unset Nonce
… …
Revision 1 Revision 2 Revision 3
Hyperledger v0.6
ledger.BeginTxnBatch()
For each txn in block:
ledger.txnBegin(txn)
bool success = LaunchDockerContainer()
ledger.Commit(txn, success)
ledger.CommitTxBatch(block.txns)
Consensus.validate(ledger, block)
Block from Consensus Layer(Either mined or received)
Hyperledger (cont’d)
Switch event from container:Case: Update Event e
ledger.SetState(e.key, e.val)
Case: Read Event e
val = ledger.GetState(e.key)
Emit ReponseEvent(val) to container
Case: …
Ledger.StateDB: Three level buffering• curStateDelta StateDelta // current executed txn
• blkStateDelta StateDelta // cached kv for txn in block
• stateImpl StateImpl // World State before block execution
Def GetState(key) {If curStateDelta[key] exists
return curStateDelta[key]If blkStateDelta[key] exists
return curStateDelta[key]If stateIml[key] exists
return stateImpl[key] }
Def PutState(key, val) curStateDelta[key] = val
Def CommitTxn(txn, success) {if success:
blkStateDelta.merge(curStateDelta)curStateDelta = {}
} Def CommitTxnInBatch(key) {stateImpl.Merge(blkStateDelta)dump stateImpl to persistence
}
Inspection Insights
• Ethereum > Hyperledger• One extra calling layer to deal with gas
• Caching for Locality• Merkle Patricia Trie (Ethereum)• BucketTree (Hyperledger)
• Buffering for Atomicity• StateDelta (Hyperledger)• Undo journals (Ethereum)
• Serial Execution• Serializability Isolation level• Boost performance with concurrent execution
• More lenient isolation level? Read Committed?
Hyperledger v1.0
For txn in block:
For rs in txn.readsets
validate rs.key and rs.version in worldstate
For ws in txn.writesets
update ledger with ws.key and ws.val
Txn 1:readsets: {k1, v1}, {k2, v2}writesets: {k3, val3}, {k4, val4}
Txn 2:
BLOCK
Our BlockChain Work and Hyperledger++1.Framework for navigating the vast design space - BLOCKBENCH2. Improving performance bottleneck with trusted hardware SGX3.New storage engine for BlockChain systems – ForkBase4.Code verification of smart contracts and a new language (ongoing)5.Provenance query processing6.MediLOT Health Data Protocol
..
.
batch execute commit
Blockchain peer
Potential bottleneck?
txs
BLOCKBENCHTo Understand and Benchmark BlockChain
Systems
46
Comment by Adrian Colyer:https://blog.acolyer.org/2017/07/05/blockbench-a-framework-for-analyzing-private-blockchains/
A.Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi, K.-L. Tan: BLOCKBENCH: A Framework for Analysing Private Blockchains. ACM SIGMOD 2017
Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, J. Wang: Untangling Blockchain: A Data Processing View of Blockchain Systems. IEEE TKDE 20p. July 2018 http://www.comp.nus.edu.sg/~ooibc/blockchainsurvey.pdf
Benchmarks
• TPC benchmark series• End-to-end macro-benchmarks• Focus on relational data model
• Yahoo! Cloud Serving Benchmark (YCSB)• For NoSQL data storage• To evaluate performance and scalability
• GridMix, PigMix, TeraSort/GraySort, etc.• Benchmark for MapReduce-like systems
• BigBench• Industry standard end-to-end benchmark• For big data processing systems
No benchmark for Private BlockChains before BLOOCKBENCH
47
Challenges
Consensus Layer (PBFT, PoW, PoS, etc.)
Smart Contract Execution Engine(Virtual Machine, Docker, etc.)
Data Model Layer(LevelDB, RocksDB, etc.)
49
Challenges
Challenge 2: A Wide variety of platforms.
Approach: start with three most mature platforms supporting smart contracts: Hyperledger Fabric, Ethereum and Parity, then generalize to support others
50
Challenges
Challenge 3: There is lack of a database-oriented workloads for blockchain.
Approach: Treat blockchain as a key-value storage coupled with an engine (smart contracts) for transactional and analytical workloads
52
Workloads
Macro-Benchmarks
Micro-Benchmarks
Data model
Execution engine
Consensus layer
Storage-oriented
Application-oriented
54
Framework
• New workloads are added by implementing IWorkloadConnector interface.
• New blockchain backendsare added by implementing IBlockchainConnector
55
Five Key Metrics
• Throughput• measured as the number of successful transaction per
second
• Latency• measured as the response time per transaction
• Scalability• measured as how the throughput and latency change when
increasing number of nodes and number of concurrent workloads.
• Fault tolerance• measured as how the throughput and latency change during
node failure, such as fail-stop, network delay and arbitrary message errors.
• Security• simulate network partition attacks, measure as stale block
rates 56
Performance Benchmark
• Hyperledger performs consistently better than Ethereumand Parity across the benchmarks. But it fails to scale up to more than 16 nodes.
• Ethereum and Parity are more resilient to node failures, but they are vulnerable to security attacks that forks the blockchain.
• The main bottlenecks in Hyperledger and Ethereum are the consensus protocols, but for Parity the bottleneck is caused by transaction signing.
Main findings (1/2)
57
Performance Benchmark
• Ethereum and Parity incur large overhead in terms of memory and disk usage. Their execution engine is also less efficient than that of Hyperledger.
• Hyperledger's data model is low level, but its flexibility enables customized optimization for analytical queries of the blockchain data.
Main findings (2/2)
58
Throughput & Latency• The gap between Hyperledger and Ethereum is because of
the difference in consensus protocol. Hyperledger is communication bound (PBFT) whereas Ethereum is CPU bound (PoW).
• Parity processes transactions at a constant rate, and that it enforces a maximum client request rate at around 80 tx/s. Parity achieves both lower throughput and latency than other systems.
• In Ethereum and Hyperledger, there is a drop of 10% in throughput and 20% increase in latency from YCSB to Smallbank. This suggests that there are non-negligible costs in the execution layer of blockchains. 59
BlockChain vs Data Systems
BlockChain not yet suitable for data processingHuge performance gap between blockchains and transactional databases
Figure: Performance of the three blockchain systems versus H-Store. 62
Suggestions
Bringing database designs into blockchain
• Decouple storage, execution engine and consensus layer from each other, then optimize and scale them independently.
* Our system ForkBase** demonstrates that a storage designed around the blockchain data structure is able to achieve better performance than existing implementations.
S. Wang, T. T. A . Dinh, Q. Lin, Z. Xie, M. Zhang, Q. Cai, G. Chen, W. Fu, B.C. Ooi, P. Ruan: ForkBase: An Efficient Storage Engine for Blockchain and Forkable Applications. VLDB 2018
63
Suggestions
Bringing database designs into blockchain
• Embrace new hardware primitives.
* For blockchain, using trusted hardware, e.g., Intel SGX, the underlying Byzantine fault tolerance protocols can be modified to incur fewer network messages.
64
H. Dang, A. Dinh, E.-C. Chang, B. C. Ooi: Chain of Trust: Can Trusted Hardware Help Scaling Blockchains? arXiv, 2 April 2018
Suggestions
Bringing database designs into blockchain
• Support declarative language.
• Declarative language will significant lower the barrier of entry to applications on top of blockchain.
• Declarative language also opens up opportunities for low-level optimizations that speed up contract execution.
• With more complex smart contracts, more database features (such as data provenance and analytics) have to be supported. 65
Suggestions
Bringing database designs into blockchain
• Sharding.
* Existing consistency protocols used in database systems do not work under Byzantine failure.
* Nevertheless, designs of sharding database systems can offer insights into realizing a more scalable shardingprotocol for blockchain.
* The main challenge with sharding is to ensure consistency among multiple shards. 66
Summary: Scalability Issues!!
Limited throughpute.g., 7-10 tps
Small network size e.g., dozens of nodes
Desired Solution: High throughput (e.g., thousands tps) on large network size (e.g., thousands of nodes)
BlockChains on Trusted Hardware
H. Dang, A. Dinh, E.-C. Chang, B. C. Ooi: Chain of Trust: Can Trusted Hardware Help Scaling Blockchains? arXiv, 2 April 2018
Existing Scaling Proposals
BFTLottery-based:
PoW, PoS
A2M, TrInc, Hypster, MinBFT, CheapBFT
Elastico, OmniLedger, ChainSpace
PoET
Eliminate equivocation
using trusted logSharding
Replace PoW with trusted randomness
Both trusted log and trusted randomness can be implemented using trusted hardware, e.g. Intel SGX
Intel SGX● Enclave Execution
○ Run a non-privilege process inside a hardware-protected execution environment (or enclave)
○ No other processes, even the OS, can access enclave memory or tamper with its execution → enclave code is treated as a blackbox to other process
● Remote Attestation○ An attesting enclave demonstrates to a validator that it has been
properly instantiated with the correct code
● Unbiased Randomness○ Provides hardware-assisted unbiased random numbers
● Trusted Elapsed Time○ Measures elapsted time (in seconds) relative to a reference point
Design Principles for Scalability
● Scale up by scaling down○ Exploiting trusted hardware to reduce the number of nodes that take
parts on the consensus; i.e., effective network size○ Smaller effective network size means less communication overhead,
lower rate of stable blocks and better throughput
● Prioritize consensus messages○ Assigning importance scores to different types of messages, with
consensus messages carrying the highest score
Following these principles, we optimize AHL, PoET and shard creation of sharding protocols
Scaling BFT: AHL and AHLR
● AHL requires n = 2f+1, while HL (vanila-pbft) needs n = 3f+1
● AHLR reduces communication complexity to O(n) but is more prone to network failure and view changes
AHL+: Optimizing network communication
● Prioritize the consensus messages by dividing the network queue into two parts: one for request, the other for consensus messages
● Remove multicast: replica only forwards requests to leader instead of multicasting them to the entire network
Summary: What we Did
1. Analyzed existing scaling proposals
1. Identify their limitations
2. Proposed two design principles to scale consensus protocols1. Scale up by scaling down
2. Prioritize consensus messages
3. Designed optimizations that improve state-of-the-art solutions1. Improve HyperLedger throughput by 7x2. Improve PoET’s throughput by 5x3. Improve shard creation of sharding protocols by 35x
ForkBase: A Native StorageEngine for BlockChain
79
Comment by Adrian Colyer:https://blog.acolyer.org/2018/06/01/forkbase-an-efficient-storage-engine-for-blockchain-and-forkable-applications/
Paper:S. Wang, T. T. A . Dinh, Q. Lin, Z. Xie, M. Zhang, Q. Cai, G. Chen, W. Fu, B.C. Ooi, P. Ruan: ForkBase: An Efficient Storage Engine for Blockchain and Forkable Applications. VLDB 2018
ForkBase Architecture
Application
View
APIs
Representation
Physical
Admin 𝑨 Admin 𝑩
put(object) → versionget(version) → {objects}merge({objects}) → object
Access Control
content-based
Data Security
privacy, integrity
Consistency Model
merge semantics
Transactions
OLTP BlockchainGit
Collaborative Analysis
BlockChain Data Model in ForkBase
• KV Store• Customized structures
• Linked block• State Merkle tree• State delta• …
• Hard to implement
• ForkBase• Achieve with built-in types
• UBlob• UMap• …
• Easy to maintain• 10+ lines for each structure
⋯ ⋯
Blockchain
UStore
FID
Txnsprev_hash
Blob
Data (Blob)
Map Smart Contract ID
......
......
Map Data Key Data Version
... ...
... ...
⋯ ⋯
Data (Blob) Data (Blob)⋯ ⋯
⋯ ⋯
Blockchain
InternalStructure
State Hash
Txnsprev_hash
Block
State Delta
StateMerkle Tree
Rocksdb
KV Store
Contract ID Key Value
⋯
⋯
Analytic-Ready BlockChain Backend
• Analytic on blockchain is expensive• Need to scan whole block history to extract information
• Built-in data types in ForkBase to support fast analytics
State Scan Query Block Scan Query
Online Operations in BlockChain
• Fast transactions with stable performance• Analytic functionalities do not degrade common online operations
• Data access latency is more stable (UMap v.s. Merkle Tree)
Client Throughput Data Access Latency
Summary of ForkBase
•Three representative, complex applications -- a blockchain platform, a wiki service and a collaborative analytics application -- were implemented and benchmarked
• ForkBase improves these applications in terms of coding complexity, storage overhead and query efficiency.
84
US$28bn2016 Global Market Size
AsiaFastest growing EHR market
US$38bnEst. Market Size 2025
Transparency Market Research: Global Electronic Health Records Market: Snapshot 2017
OPPORTUNITY – EHR
US$600m2014 Global Market Size
10xGrowth in the next 5 years
US$6.6bnEst. Market Size 2021
OPPORTUNITY – AI
Electronic Health Records (EHR) are digital medical records
CONCERNS
Fragmented
Health Records
Lack Of Patient
Ownership/Privacy
No Artificial
Intelligence Integration
Multiple EHR solutions
in the market-not
compatible, leading to
information silos
• Patients do not control
access to their own health
data
• Differential consent choices
not captured
Existing systems not
optimised for data
abstraction/analytics and
personalised medicine
WHAT IS EHR?
BlockChain and AI enabled Healthcare
• BlockChain (BC) acts as a tamper-evident storage for archiving Healthcare Records from different healthcare providers
• BlockChian acts a “Central Healthcare Record” repository
• It enables Data Provenance, Data Analytics, and Medical-care everywhere based on patient’s preference
• It will transform Healthcare management and research!
89
MediLOT’s Technologies
DualBlockchain
Ethereum & Hyperledger++
• Enhanced Hyperledger with scalable consensus
• Thoroughput up by 7x (40x with sharding)
AnalyticsGEMINI
• Generalisable Medical Information Analysis and Integration Platform, the underlying AI suite that supports big data analytics and personalised medicine
Data Storage Forkbase
Proprietary storage with rich semantics, immutability and data sharing, Blockchain optimised native storage system
Patient CompaniesResearchers, Insurers, Pharma
Hospital/Government
• Privacy and control over
data
• Validated personal data
• Rewarded for personal data
• Personalised insights
• Access to aggregated anonymised
data
• Insights from data to drive
business
• Privacy and control over data
• Data security
• Clean and validated data
• Data sharing with
researchers/admin/others
STAKEHOLDER NEEDS
THE MEDILOT SOLUTION
1. Holistic
Every patient will have a
complete longitudinal
health record: their own
health story that they can
access at any institution
2. Patient-centric
The patient holds
his/her own private key
and has fine control
over who can view their
medical records
3. Personalised
Using an advanced analytics
overlay (GEMINI), MediLOT
facilitates personalised
treatment strategies
4. Decentralised
Patients’ data is stored in
different locations,
eliminating the risk of a
single catastrophic breach
HOW DOES MEDILOT WORK?
Hospital Patient Data Requestor
Permissioned (Hyperledger++)
Responsible for aggregation of patient EHR
Block 1 Block 2 Block 3 Block N
Block 1 Block 2 Block 3 Block 4 Block N
Block 5 Block 6ERC20
Token
Contract
Registry
Contract
Consent
Contract
DUAL BLOCKCHAIN SCHEMA
Public (Ethereum)
Allows for transfer and crediting of ERC20 LOT tokens (MediLOT utility token)
Legend: Data Generation Process Data Request Process
Request patient’s consent
Information entered in local
EHR
Access data through GEMINI Hospital
Database
Unique hash generated
for
every data entry and
sent to
blockchainCheck patient’s consent
BlockchainApprove/Reject
data creation
Write consent
Request patient’s consent
Access data through GEMINI
Doctor
Data Requestors
(Pharmaceutics,
Research,
Insurance,
Government)
Patient
USER INTERACTIONS
Legend:
Receive Analytics
TOKEN UTILITY
Patient
Receive LOT: LOT is transferred to data contributors Stake LOT: LOT is sent to a smart contract and held to incentivise good behaviour
Contribute LOT: LOT is fully utilised
Contribute Data
Develop Applications
Developers/
Service Providers
Access Applications
Researchers
Government
Partner Hospitals/
Institutions
Utilise Data
Enroll onto
Platform
Conclusions
• Blockchain, like its original application (cryptocurrency), is going to stay and evolve
• Blockchain, at this moment, is NOT yet able to support heavy workload and large network (most ICOs over promised!)
• All three major components need to be improved:• Consensus model• Execution engine• Data storage engine
97
Thanks!
http://www.comp.nus.edu.sg/~dbsystemhttp://www.medilot.com
http://www.medilot-tech.com
98