1. LedgerDB: A Centralized Ledger Database
for Universal Audit and Verification
Xinying Yang† , Yuan Zhang† , Sheng Wang§ , Benquan Yu† ,
Feifei Li§ , Yize Li† , Wenyuan Yan†
†Ant Financial Services Group §Alibaba Group
Proceedings of the VLDB Endowment, August 2020
2. Motivation:
Decentralized ledger
→ Low throughput
→ High latency
→ High storage overhead
Centralized ledger
→ High throughput
→ Low latency
→ Low storage overhead
Real-world use cases only seek for tamper resistance
Simple cryptographic protection is enough (e.g., merkle tree)
Threat model is not realistic
Consortium members can collectively deceive an external auditor
(i.e., fabricate fake evidence without being noticed)
Existing centralized ledger assumes trustful service provider
(e.g., AWS QLDB)
But, single point of failure…
Blockchain immutability induces obsolete storage overhead
Permissioned Blockchain
3. Background
Many blockchain apps deployed on a Blockchain-as-a-Service (BaaS)
which (eventually) leads to a centralized infrastructure
maintained by a single service provider
Re-examine the necessity of its decentralization
Reform decentralization in permissioned blockchain
4. Auditability
⚫ Auditability is the capability of observing user actions
and verifying integrity and authenticity
⚫ Internal audit
• Ensures that an internal user of the ledger can verify all
transactions conducted by all other users
⚫ External audit
• Ensures that an external auditor can verify all transactions
conducted by all users and ledger service provider (LSP)
5. Threat Model
⚫ Server-side malicious tampering
• An adversary can compromise user(s) or LSP and
tamper/remove transaction history
⚫ LSP-user collusion tampering
• One or more uses can collude with the LSP as the
adversary to cheat an external auditor
⚫ Trusted third-party Time Stamping Authority (TSA)
• Provides universal time endorsement
6. Design Goals
⚫ Strong external auditability
⚫ High write performance
⚫ Data removal (+hiding) support
8. LedgerDB: Overview
Receives client requests and preprocesses, an
d then dispatches them to the ledger server
Manages the runtime metadata of the
entire cluster and coordinates cluster-
level events
Process requests, while interacting
with the underlying storage layer
9. LedgerDB: Data Model and APIs
Transaction
Journal (entry)
Transaction
Transaction
Transaction
Ledger instance
(ledger_uri)
Transaction
Block
Journal
Sequence# (jsn)
0
1
2
3
n
10. LedgerDB: Data Model and APIs
// Hide journal by jsn or clue
// Rollback to the purged_point
// remove obsolete journals from ledger
// assign trust level
to jsn
12. LedgerDB: Transaction Processing
⚫ Most blockchain: Order-Execute
• Execute transactions serially, leading to extremely low
throughput
⚫ Hyperledger Fabric: Execute-Order-Validate
• Support concurrent execution of multiple transactions,
which however declines significantly when the conflict
rate is high during validation
⚫ LedgerDB: adopts a novel Execute-Commit-Index
• Combines execution and validation for transaction to be
validated as early as possible before the completion of its
entire execution
• better utilizes centralized concurrency control and
distributed execution techniques to improve throughput.
14. LedgerDB: Transaction Processing Workflow
collects multiple executed transactions & processes them in batch
arranges them in a global order
persists them to the storage system
can modify World State
16. Verification & Audit: Batch Accumulated Merkle Tree
Block-intensive model (bim) Transaction-intensive model (tim)
To verify the existence of specified transactions, there are two typical entanglement
models used in blockchain-like systems.
PrevHash
PrevHash
PrevHash
Tx Integrity: Merkle Tree within a block
Block Integrity: Hashchain across blocks
Insertion cost = O(d)
For m transaction insertions, O(d * m) → slow
Tx verification cost = O(logn)
Tree depth
= d
O(m + d)
Batch Accumulated Merkle Tree’s Insertion Cost
m = batch size
no concept of a block of transactions (e.g., Libra)
Benefits from both model
Block size = n
18. LSP-user collusion tampering
TSA: a time notary authority, which can prove that a piece of data exists
before a certain time point
Universal Time Notary Anchors
External
auditor
User
User
LSP
Fabricated
fake evidence
Request
transaction history
<출처: 행안부 타임스탬프 적용 안내서>
Blockchain network
19. Universal Time Notary Anchors
Defines a special type of journal: TSA journal, endorsed by TSA
ledger snapshot (i.e., a ledger digest)
timestamp, signed by TSA
TSA journal
Points to the hash of its pr
evious TSA journal
Anchor
frequency
20. Verifiable Data Removals
⚫ LedgerDB breaks the immutability in most blockchain
but still preserves data verifiability
⚫ Data removal operators
• purge : removes obsolete records to save storage cost
• occult : hides violating records to resolve regulatory issues
21. Verifiable Data Removals: purge()
⚫ Deletes a set of contiguous (obsolete) journals starting
from genesis to a designated journal, and then
generates a pseudo genesis block.
pur_jsn
Genesis
Block
purge
Pseudo Genesis
Block
system metadata
(e.g., creator, initial members)
+
Status(e.g., memberships)
migrate
22. Verifiable Data Removals: purge()
⚫ Appends a purge journal on ledger.
⚫ Requires multi-signatures from the ledger creator (or
DBA) and all related members
23. Evaluation: Setup
⚫ Deploy LedgerDB on Alibaba Cloud
⚫ 2-node cluster, where each node runs CentOS 7.2.1511
and is equipped with Intel(R) Xeon(R) Platinum 2.5GHz
CPU, 32GB RAM, and 1TB ESSD storage (with
throughput at 632MBps and 53K IOPS)
⚫ All nodes are connected via 25Gb Ethernet
28. Conclusion
⚫ Proposes LedgerDB, a centralized ledger database
that supports universal audit and verification
⚫ LedgerDB offers
• High performance
• High verification efficiency
• Verifiable data removals
⚫ LedgerDB can be a fascinating alternative to
permissioned blockchains.
