ECS 265: Distributed Database Systems

• Home page

Nakamoto Concensus is voting by solving puzzles instead of relying on a central certificate authority (identity).

• ACCT (Atomic Cross-Chain Transaction) Model
• ACCC (Atomic Cross-Chain Commitment)
  • ACCCTW: Centralized Trusted Witness
  • ACCCWN: Permissionless Witness Network
    • Need a witness blockchain (miners are the witnesses on ACCTs)
  • Cross-Chain Evidence Validation
    • Simple but impractical: require all the miners of every blockchain to serve as validators to all other blockchains. Alternatively, miners one one blockchain can run light nodes of other blockchains. Does not scale as the number of blockchain increases.
    • Paper's proposal: push the validation logic into the code of a smart contract in the validator blockchain.
• ACCCWN Analysis
  • Atomicity Correctness Proof
  • Scalability: A permissionaless network of witnesses that coordinates ACCTs does not limit the scalability of the ACCCWN protocol.
  • Handling Complex ACCT Graphs

Questions:

• ACCT requires every involved blockchain to be able to run smart contracts. Bitcoin does not support smart contract natively, why use it as an example?
• Roll our own witness network or build on top of an existing network, such as ResilientDB?
• If I redeem then reject immediately, then it's possible I ended up redeem? (redeem block wins)

Notes:

• Manual work: deploy smart contract, submit request/evidence

• Be interactive
• 30 presentation and 20 mins Q&A
• could use the book ordering example throughout the slides
• not black or white, different parts of the same service can choose different points in the spectrum

• buffer pool: data in main memory
• ACID
  • Atomicity: all actions are exectued or nones are
  • Consistency:
    • A set of rules/constraints about the data must be satisified at the beginning and at the end of each transaction.
    • Multiple copies of data must be consistent.
  • Isolation: already satisified by A, C and D in a single-threaded database context. The schedule of concurrent transactions can be mapped to a sequential transaction schedule correctly.
  • Durability: if a transaction is commited, the data must be persistent. Otherwise, the data must not write to DB.

Core Suggested Topics:


• Cross-chain Deals and Adversarial Commerce. VLDB'20

• Atomic Commitment Across Blockchains. VLDB'20 

• Cerberus: Minimalistic Multi-shard Byzantine-resilient Transaction Processing. arXiv'20

• Dispel: Byzantine SMR with Distributed Pipelining, arXivs
FireLedger- A High Throughput Blockchain Consensus Protocol. VLDB'20

• In Search of an Understandable Consensus Algorithm. USENIX ATC'14

• Matchmaker Paxos: A Reconfigurable Consensus Protocol [Technical Report]. arXiv'20



Others:


• Near Protocol

• Chainspace: A Sharded Smart Contracts Platform
• Chainweb: A Proof-of-Work Parallel-Chain Architecture for Massive Throughput
• POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK

Applications:

• Contact tracking
• Election/Voting
• Supply chain

Project could be:

• Prototype the protocol (preferrably in ResilientDB) and write a report.

2-phase commit protocol.

Consistency, Availability and Partition-tolerant.

• Slides

Consistency:

• State consistency in CAP
• Operation consistency in ACID

How to run ResilientDB.

• PBFT
  • Primary node serves as sequencer (time and transaction)