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

BlockChain 101

4

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

Cryptography

Tamper-proof log blocks using hash pointer

11

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

13

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?

BlockChain Systems vs Data Systems

22

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

}

Bucket Tree

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

Performance Benchmarking

43

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

Challenge 1: A vast design space

48

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

51

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

53

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

Enclave Execution

Enclave

Code

Other

Programs

OS/VMM

RAM

EPC

Ring 3

Ring 0 - 2

Trusted

Untrusted

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

MediLOTTransformaing Healthcare Through BlockChain and AI

MediLOT Technologies Pte Ltd

85

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