• Questions & Summary
• Introduction
  • Background & Motivation
  • Goal
  • Gap
  • Challenge
• Technique details
  • Design Goals
  • System Overview
  • Journal management
    • Journal Structure:
    • Tx processing
      • Execute phsae
      • Commit phase
      • Index Phase
    • Failure Recovery
  • Verification and Audit.
    • Batch Accumulated Merkle Tree
    • Universal itme Notary anchors:
  • Native Provenance
  • LedgerDB in Production
• Evaluation

Questions & Summary

Introduction

Background & Motivation

Decentralization is a fundamental basis for blockchain systems, including permissionless (Bitcoin, Eth) and permissioned systems (Hypeledget Fabric, Corda). However, the decentralized architecture reduces the system performance in low throughput, high latency, and significant storage overhead.

Moreover, many applications deploy their permissioned blockchain node in a single service provider, leading to a centralized infrastructure.

Thus, the necessity of decentralization property needs to be re-examined.

Goal

This paper proposes a centralized ledger database to provide tamper-evidence and non-repudiation features. And with the following properties:

• Strong auditability.
• Broad verification coverage.
• High throughput (write/read)
• Low storage cost.

Gap

1. Most existing ledger and blockchain systems only support internal audits, and fewer provide external audits.
2. Permissioned blockchains are significantly limited by their decentralized architecture.
3. Most existing systems don’t support data removal operations and incur high storage costs.

Challenge

1. Centralized Required: Many permissioned blockchains only seek tamper resistance from cryptography-protected structures, such as hashed chains and Merkle trees. And decentralization and smart contracts are not used.
2. Threat Model: The permissioned blockchains have limited auditability since consensus protocols are deceptive for external auditors.
3. LSP Dependent: Existing centralized ledger databases (QLDB and Oracle) assume a trustful ledger service provider (LSP), which is hard to achieve.
4. High Storage Cost: Immutability provided in the existing system requires storing data permanently and disclose, leading to increased storage overhead and cost.

Technique details

Design Goals

The paper tries to provide strong audibility (internal and external), high write performance, and data removal support.

• Auditability: The capability of observing user actions and operation trails. For example,g. the auditor should confirm that the data content has not been tampered and the issuer is authentic.
  • Internal audit: internal users can observe and verify the authenticity of all actions conducted by all participants.
  • External audit: the third party can observe and verify the authenticity of all transactions conducted by all participants.
• Threat Model:
  • Assume users’ and LSPs’ identities are trusted; third-party timestamp authority is trusted; honest majority;
  • Tolerate two attacks: server-side malicious tampering and LSP-user collusion tampering. And there are three threat models derived from those two attacks.
    • Threat-A: server-side attackers tamper with incoming transactions when the user’s request arrives.
    • Threat-B: server-side attackers tamper (update, delete, insert) historical transactions to cheat users.
    • Threat-C: LSP-user attackers tamper (update, delete, insert) historical transactions to cheat users.

System Overview

LedgerServer and LedgerProxy are stateless services. Storage replicated using raft protocol.

Each transaction is saved in one journal; multiple journals are grouped into a block, and multiple blocks are grouped into a ledger.

Multiple APIs are supported, such as append, retrieve, verify, purge, occult, recall, and delete.

Journal management

Committed transactions are tamper-resistant, non-repudiable, and persistent.

Journal Structure:

Client sign with PK => resolves the threat-A.

Journal-receipt => resolves threat-B.

Tx processing

The order-and-execute approach has low throughput, while the execute-order-validate (Hyperledger Fabric) approach has high declines when the conflict rate is high in validation.

The paper uses an execute-commit-index transaction management approach.

Execute phsae

This is executed on ledger proxy for better scalability.

Functionalities:

• Verift the validity of tx: Consults the authorization module to check where sender has permission to perform this ops.
• Store the verified tx to Tx Store.
• Execute the tx and update meta-data store (World State.)
• Send to ledger server for commit phase.

Commit phase

This is exeuted on ledger server.

Functionalities

• Collect journals from previous phase and process in batch.
• Assign each journal with a serial number based on its server arrival sequence.
• Committed them to JournalInfo Store.

Index Phase

This is executed on ledger server for subsequent data retrieval and verication.

Functionalities

• clue index
• bAMT accumulator
• block information

Failure Recovery

The system handles ledger server and ledger proxy crashes. On each crash, it reload data from storage and reply the operations.

Recovery based on list of journals committed in journalInfo store.

Verification and Audit.

The system supports two verfications

• Internal verification: verify at the server side and LSP must be fully trusted. This has high efficiency.
• External verification: verify at the client side and LSP is distrusted.

Batch Accumulated Merkle Tree

Verify the existence of txs.

Universal itme Notary anchors:

To resolve threat-C (provide external auditability).

TSA is a time notary authority, which can prove that a piece of data exists before a certain time point.

The paper uses TSA journal to store a ledger snapshot, and a timestamp signed by TSA in entirety.

Native Provenance

LedgerDB in Production

Evaluation

---

• ← Previous Post
• Next Post →