Download paper from PVLDB:
http://www.vldb.org/pvldb/vol12/p975-ruan.pdf
The success of Bitcoin and other cryptocurrencies bring enormous interest to blockchains. A blockchain system implements a tamper-evident ledger for recording transactions that modify some global states. The system captures entire evolution history of the states. The management of that history, also known as data provenance or lineage, has been studied extensively in database systems. However, querying data history in existing blockchains can only be done by replaying all transactions. This approach is applicable to large-scale, offline analysis, but is not suitable for online transaction processing.
We present LineageChain, a fine-grained, secure and efficient provenance system for blockchains. LineageChain exposes provenance information to smart contracts via simple and elegant interfaces, thereby enabling a new class of blockchain applications whose execution logics depend on provenance information at runtime. LineageChain captures provenance during contract execution, and efficiently stores it in a Merkle tree. LineageChain provides a novel skip list index designed for supporting efficient provenance query processing. We have implemented LineageChain on top of Hyperledger and a blockchain-optimized storage system called ForkBase. Our extensive evaluation of LineageChain demonstrates its benefits to the new class of blockchain applications, its efficient query, and its small storage overhead.
ICT role in 21st century education and its challenges
Fine-Grained, Secure and Efficient Data Provenance on Blockchain Systems
1. Fine-Grained, Secure and Efficient Data
Provenance on Blockchain Systems
Pingcheng RUAN, Gang CHEN, Tien Tuan Anh DINH,
Qian LIN, Beng Chin OOI, Meihui ZHANG
2. Blockchain Is a Class of Database
Blockchain
Distributed
Database
Database
Bitcoin
Distributed
Transactional
Systems
5. Provenance-dependent Contracts
• Previous transfer precondition:
– Enough balance from the sender
– CURRENT STATE ONLY
• New transfer precondition:
– Historical balance > threshold
– Recipient not transacted with certain blacklisted addresses recently
– HISTORICAL STATE & PROVENANCE INFO
6. Workarounds
Workaround 1:
•Dump every thing into current
state
•Effort-needed, expensive,
error-prune
Workaround 2:
• Offline analytics + Online
transactions
• Break of serializability
• Transaction-ordering attacks
Workaround 3:
• Minimum system
instrumentation
• NOT protocol level (e.g.,
Hyperledger Fabric v1.0+)
• Data tampering
Holistic Approach:
• Protocol-level enhancement
Secure
• Performance-aware
Efficient
Account1_v1: 10
Account1_v2: 20
Account1_v3: 15
Account2_v2: 12
7. Challenges
• With clearly-defined transformation semantics
• E.g
• Map and reduce in Hadoop
• Select, join and aggregation in SQL
NO standardized operations
• Tamper evidence
• Integrity proof
Byzantine environment
• Gas mechanism
• Verifier’s dilemma
Ever-growing ledger
13. Execution Layer
• Receive
– Contract invocation context
– Provenance specification
• Compute
– Transaction results
– Concrete dependency
• Prepare Merkle DAG
– Introduce one layer of direction
– Hash reference to encode
provenance backward
dependency
14. Execution Layer
• Forward tracking
– Problem: Undecided forward dependency during state update
• Solution
– Lazily store forward dependency on the successor state entry
15. Storage Layer
• Problem
– Efficient version-based (historical) query for a state ID
• Solution:
– Deterministic Append-only Skip List
– Hash-based reference
After appending
versions 12 and 16
16. Evaluation
• MICRO benchmarking (vs. flat storage)
– Preference to recent version query (with DASL)
– More efficient BFS enabled by backtrack (with ForkBase)
• MACRO benchmarking (applied to Hyperledger Fabric v0.6 and
v1.3)
– Negligible runtime overhead
o Tiny proportion of latency
– Negligible storage overhead
o >70% of space for blocks
o 25% for historical states
o 2~4% for DASL indexes and hash pointers
17. Performance of Provenance Query
• vs. Workaround 2
– Compute data provenance offline and conditionally trigger online transaction
18. Micro Performance of Provenance Query
• vs. Workaround 1
– Dump everything into the current state
• vs. Workaround 3
– Use Hyperledger Fabric’s built-in HistoryDB