Decentralized crypto-currencies based on the Blockchain architecture, such as Bitcoin, can only process a few transactions per second in the whole network, resulting in permanent congestion and high transaction fees, which limits their attractiveness and adoption. New generations of crypto-currencies tend to tackle the scaling issue either by giving up on full decentralization, or by lowering their security levels.
This sounds like there’s some kind of scalability trilemma at play. The trilemma claims that blockchain systems can only at most have two of the following three properties: Decentralization (…), Scalability (…), Security (…). - Vitalik Buterin
Blockclique solves the scalability trilemma by allowing the production of parallel blocks in a multithreaded block graph,
while transaction sharding ensures that transactions of parallel blocks are compatible by construction.
Our open-source simulations show that the Blockclique architecture scales beyond 10,000 transactions per second,
while staying decentralized and secure (see the technical paper or the blog post introduction).
The Blockclique is therefore a promising basis for future crypto-currencies, and could bring decentralization back into the spotlight.
On this website you can interact with a live demonstration of the Blockclique architecture, with a Proof-of-Stake node selection mechanism:
You can explore a live growing blockclique, create a wallet, control a new staker (receiving free coins). Within a few minutes, your staker will produce some blocks and receive block rewards. Please send coins to your friends!
We simulate on a single server (4Ghz 8-cores) a network of nodes that produce blocks, send blocks to peers and compute the best clique of compatible blocks. We compute the time for each message and block to be transmitted from one node to another depending on the simulated latency and bandwidth between each node of the network (average bandwidth of 64Mbps and latency of 100ms, similar to the Bitcoin network).
The parameters of Blockclique are the number of threads T, the average time between two blocks in each thread t0, the maximum block size BS, and the finality parameter F. We set T=32 threads, t0=16s, BS=675 kB and F=64 blocks. Due to cpu constraints (hundreds of nodes on the same server), we do not simulate endorsements, so we assume E=0, and blocks are by default filled with dummy transactions.