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.
CQL supports 2 kinds of consensus algorithm:
- DPoS (Delegated Proof-of-Stake) is applied in
Eventually consistency modedatabase and also
Layer 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 algorithm
- BFT-Raft (Byzantine Fault-Toleranted Raft)bft-raft is applied in
Strong consistency modedatabase. We named our implementation
Kayak. The CQL miner leader does a
CQL database consistency mode and node count can be selected in database creation with command
cql create -db-eventual-consistency -db-node 3
|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|
|Nodes for HA||3||15||?||3|
|Column Level ACL||N||Y||?||Y|
|Data Format||File||Key-value||Document||Filefuse, Key-value, Structured|
|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)
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 limited
Atomicitysupport. That is even under strong consistency mode, CQL transaction is only supported on the leader node. If you want to do "read
vback" parallelly and atomically, then the only way is "read
vfrom the leader,
vback to leader"
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