Folders and files
| Name | Name | Last commit date | ||
|---|---|---|---|---|
CovenantSQL(CQL) is a Byzantine Fault Tolerant relational database built on SQLite:
- ServerLess: Free, High Availabile, Auto Sync Database Service for Serverless App
- SQL: Most SQL-92 support.
- Decentralize: Running on Open Internet without Central Coordination.
- Privacy: Access with Granted Permission and Encryption Pass.
- Immutable: Query History in CQL is Immutable and Trackable.
- Permission: Column Level ACL and SQL Pattern Whitelist.
- Open source alternative of Amazon QLDB
- Low cost DBaaS
- Just like filecoin + IPFS is the decentralized file system, CQL is the decentralized database
CQL client supports:
- macOS X 10.9+
- Linux 2.6.23+ (x86, x86_64, armeabi-v7a, arm64-v8a)
-
🍺 Homebrew users can just run:
brew install cql
-
non-Homebrew users can run:
sudo bash -c 'curl -L "https://mac.gridb.io/cql" | tar xzv -C /usr/local/bin/ --strip-components=1'
-
Just run：
sudo bash -c 'curl -L "https://linux.gridb.io/cql" | tar xzv -C /usr/local/bin/ --strip-components=1'
To continue: TestNet Quickstart
CovenantSQL Testnet is already released, have a try.
- 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 mode database 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 Xenomint.
- BFT-Raft (Byzantine Fault-Toleranted Raft)bft-raft is applied in Strong consistency mode database. We named our implementation Kayak. The CQL miner leader does a Two-Phase Commit with Kayak to support Transaction.transaction
CQL database consistency mode and node count can be selected in database creation with command cql create '{"UseEventualConsistency": true, "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 |
| 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) |
-
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 Atomicity support. That is even under strong consistency mode, CQL transaction is only supported on the leader node. If you want to do "read v, v++, write v back" parallelly and atomically, then the only way is "read v from the leader, v++, write v back 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
DH-RPC := TLS - Cert + DHT
| Layer | Implementation |
|---|---|
| RPC | net/rpc |
| Naming | Consistent Secure DHT |
| Pooling | Session Pool |
| Multiplex | smux |
| Transport Security | Enhanced TLS |
| Network | TCP or KCP for optional later |
- Global Network Topology Emulator is used for network emulating.
- Liner Consistency Test
Our team members published:
- Thunder crystal: a novel crowdsourcing-based content distribution platform
- Analyzing streaming performance in crowdsourcing-based video service systems
- Performance Analysis of Thunder Crystal: A Crowdsourcing-Based Video Distribution Platform
that inspired us:
- Bitcoin: A Peer-to-Peer Electronic Cash System
- S/Kademlia
- vSQL: Verifying arbitrary SQL queries over dynamic outsourced databases
Strong consistency bench result (2 miners, 8 core aws c5.2xlarge):
As seen above, the concurrency pressure on the database increased gradually in the first 5 hours, and the write TPS also increased. When the TPS no longer grows, the concurrent pressure is maintained for 100 hours.
- CovenantForum
- Weibo Bot @BlockPin
- Markdown Editor with CovenantSQL sync
- Web Admin for CovenantSQL
- How CovenantSQL works(video)
If you are a developper of password management tools just like 1Password or LastPass. You can use CQL as the database to take benefits:
- Serverless: no need to deploy a server to store your user's password for sync which is the hot potato.
- Security: CQL handles all the encryption work. Decentralized data storage gives more confidence to your users.
- Regulation: CQL naturally comply with GDPR.
CQL miners are deployed globally, IoT node can write to nearest CQL miner directly.
- Cheaper: Without passing all the traffic through a gateway, you can save a large bandwidth fee. And, CQL is a shared economic database which makes storage cheaper.
- Faster: CQL consensus protocol is designed for Internet where network latency is unavoidable.
For example, you are the most detailed Bitcoin OHLC data maintainer. You can directly expose an online SQL interface to your customers to meet a wide range of query needs.
- CQL can limit specific SQL query statements to meet the needs while also balancing data security;
- CQL can record SQL query records on the blockchain, which is very convenient for customers to check their bills for long-tail customers and billing, like this
- For customers with high performance requirements, Slave nodes can be deployed at the customer to meet the needs of customers with low latency queries while enabling almost real-time data updates.
Thanks to the CQL data history is immutable, CQL can be used as a storage for sensitive operational logs to prevent hacking and erasure access logs.
Storing data on Bitcoin or Ethereum is quite expensive ($4305 / MB on Ethereum 2018-05-15). Programming is very complicated due to the lack of support for structured data storage. CQL gives you a low-cost structured SQL database and also provides more room for ĐApp to exchange data with real-world.
