Architecture
3 Layers Arch
- Layer 1: Global Consensus Layer (the main chain, the middle ring in the architecture diagram):
- There will only be one main chain throughout the network.
- Mainly responsible for database Miner and the user’s contract matching, transaction settlement, anti-cheating, shard chain lock hash and other global consensus matters.
- Layer 2: SQL Consensus Layer (shard chain, rings on both sides):
- Each database will have its own separate shard chain.
- Mainly responsible for: the signature, delivery and consistency of the various Transactions of the database. The data history of the permanent traceability is mainly implemented here, and the hash lock is performed in the main chain.
- Layer 3: Datastore Layer (database engine with SQL-92 support):
- Each Database has its own independent distributed engine.
- Mainly responsible for: database storage & encryption, query processing & signature, efficient indexing.
Consensus Algorithm
CQL supports 2 kinds of consensus algorithm:
- DPoS (Delegated Proof-of-Stake) is applied in
Eventually consistency modedatabase and alsoLayer 1 (Global Consensus Layer)in BlockProducer. CQL miners pack all SQL queries and its signatures by the client into blocks thus form a blockchain. We named the algorithmXenomint. - BFT-Raft (Byzantine Fault-Toleranted Raft)bft-raft is applied in
Strong consistency modedatabase. We named our implementationKayak. The CQL miner leader does aTwo-Phase CommitwithKayakto supportTransaction.transaction
CQL database consistency mode and node count can be selected in database creation with command cql create -db-eventual-consistency -db-node 3
Comparison
| Ethereum | Hyperledger Fabric | Amazon QLDB | CovenantSQL | |
|---|---|---|---|---|
| Dev language | Solidity, ewasm | Chaincode (Go, NodeJS) | ? | Python, Golang, Java, PHP, NodeJS, MatLab |
| Dev Pattern | Smart Contract | Chaincode | SQL | SQL |
| Open Source | Y | Y | N | Y |
| Nodes for HA | 3 | 15 | ? | 3 |
| Column Level ACL | N | Y | ? | Y |
| Data Format | File | Key-value | Document | Filefuse, Key-value, Structured |
| Storage Encryption | N | API | Y | Y |
| Data Desensitization | N | N | N | Y |
| Multi-tenant | DIY | DIY | N | Y |
| Throughput (1s delay) | 15~10 tx/s | 3500 tx/s | ? | 11065 tx/s (Eventually Consistency) 1866 tx/s (Strong Consistency) |
| Consistency Delay | 2~6 min | < 1 s | ? | < 10 ms |
| Secure for Open Internet | Y | N | Only in AWS | Y |
| Consensus | PoW + PoS(Casper) | CFT | ? | DPoS (Eventually Consistency) BFT-Raft (Strong Consistency) |
FootNotes
BFT-Raft: A CQL leader offline needs CQL Block Producer to decide whether to wait for leader online for data integrity or promote a follower node for availability. This part is still under construction and any advice is welcome.
Transaction: Talking about
ACID, CQL has full "Consistency, Isolation, Durability" and a limitedAtomicitysupport. That is even under strong consistency mode, CQL transaction is only supported on the leader node. If you want to do "readv,v++, writevback" parallelly and atomically, then the only way is "readvfrom the leader,v++, writevback to leader"FUSE: CQL has a simple FUSE support adopted from CockroachDB. The performance is not very ideal and still has some issues. But it can pass fio test like:
fio --debug=io --loops=1 --size=8m --filename=../mnt/fiotest.tmp --stonewall --direct=1 --name=Seqread --bs=128k --rw=read --name=Seqwrite --bs=128k --rw=write --name=4krandread --bs=4k --rw=randread --name=4krandwrite --bs=4k --rw=randwrite