Detailed Explanation of CESS Mechanism (2): Blockchain Layer and the Random Rotational Selection (R²S) Consensus Mechanism

The consensus layer within the blockchain is the most crucial underlying architecture for any blockchain project. The design of the consensus layer affects the entire network’s efficiency, safety, and degree of decentralization. The public storage chain is a subdivided network of the general public chain, but the requirements for data processing efficiency are not less than that of the public chain.

The decentralized cloud storage network CESS (Cumulus Encrypted Storage System) leverages its technological advantages to have the most complex calculations processed on-chain to build a decentralized network. As the underlying infrastructure of Web3.0, CESS achieves high efficiency while maintaining a high level of decentralization, which is made possible by the implementation of CESS’s proprietary technologies and mechanisms.

Random Rotational Selection Consensus Mechanism (R²S)

To enhance the on-chain transaction processing efficiency while maintaining the decentralization of nodes, CESS adopts the Random Rotational Selection consensus mechanism (R²S) to enable block packaging and other on-chain transactions. The name of the consensus mechanism is self-explanatory: nodes that complete the on-chain consensus are selected randomly at different periods to perform the task.

The Implementation of “Randomness” and “Rotation”

Having a fair and well-designed consensus mechanism to prevent potential foul play is pivotal for any robust blockchain. The roles of consensus nodes in R²S are as follows.

All participants can opt to become candidate nodes, pending qualification to serve as consensus nodes. The system selects 11 consensus nodes from the pool of candidate nodes who meet the criteria at each time window (for example, every 10,000 blocks). These 11 consensus nodes are responsible for block generation and transaction verification. Meanwhile, candidate nodes participate in the data preprocessing procedure to prove their competency and must meet the criteria to be selected as consensus nodes by the next rotation. Any on-duty consensus node that fails to perform or acts maliciously is replaced immediately by candidate nodes and penalized with bad credits. Nodes with credit scores below standard are disqualified from being candidate nodes and must forfeit partial staking tokens if they quit.

Verifiable Random Function

The randomness of node selection is the key to a safe and fair decentralized network, and decentralization makes data more secure and prevents manipulation by dominant nodes. However, CESS’s randomness in the consensus node selection demands a stronger performance from the network’s coping mechanisms compared to most public chains. It is difficult to ensure a high level of security while maintaining network flexibility, so CESS adopts intricate algorithms to achieve this goal. Each candidate consensus node has a pair of public and private keys and calculates the random hashes using the following formula during each election.

R=VRF_Hash(SK, Seed)

P=VRF_Proof(SK, Seed)

Parameter SK is the private key of the nodes. Seed is a random text string on the CESS chain, which cannot be predicted in advance. R is the random hash output, and P is the hash proof.

The validator can easily verify that the two values are indeed generated by the node that owns the value through the above steps.

R=VRF_P2H(P)

VRF_Verify(PK, Seed, P)

PK is the public key of the nodes being verified. In the following rotation, the system selects 11 nodes with the smallest random hash results as consensus nodes. If more than 11 nodes are selected, the excessive nodes are screened out based on their credit scores.

Admission and the Quitting Procedure for Nodes

CESS does not have strict requirements for network nodes. Still, a qualified node needs to meet the basic operating and resource contribution requirements and deposit CESS tokens as a stake to pre-empt any wrongdoing. At any point a node quits, the network refunds the staking tokens in full or partially based on the node’s credit scores. The system returns the tokens in full as long as nodes follow the rules without intentional violation. This procedure prevents Sybil attacks and secures the network consensus.

The Advantages of R²S

R²S is technologically complex as a result of the deliberate consideration of the storage public chain during the design phase of CESS’s overall protocols.

Prevent “Miner’s Dilemma” and Centralization

“Miner’s Dilemma” refers to the fact that miners store useless information rather than block history to maximize their profits quickly in the storage network. These miners cannot become full nodes, leading to fewer full nodes with critical data that ensure the synchronization of the network. A network with fewer full nodes would consequently grant them too much power, which could potentially cause network centralization. Unlike other commonly used storage consensus mechanisms, CESS recognized the “Miner’s Dilemma” pitfall, so it separates storage metrics from the R²S consensus mechanism. Overall, R²S promotes a more decentralized network and prevents large nodes from acting maliciously seeking benefits as a result of centralization.

Being decentralized and Efficient

Having only 11 nodes to maintain the consensus can significantly improve the network efficiency, but the network will be overly centralized like the alliance chain. Hence, having nodes randomly selected and CESS’s low hardware requirement encourages more individuals to participate as nodes, further decentralizing the network to solve this issue.

Processing Transactions On-Chain

CESS stores all transactions, contract confirmation and uploaded files’ metadata on-chain. Many other projects tend to process partial data off-chain to ensure network efficiency due to their low on-chain processing speed, yet it requires multiple mechanisms to guarantee data security. CESS’s superior technological ability to process transactions on-chain allows metadata to be stored on-chain without slowing down the network. In addition, data file searching can be done through on-chain metadata, and having more data information stored on-chain can better protect its authenticity.

In the actual process, consensus nodes retain a database of all metadata to prioritize network efficiency. Data indexing will start from this database first and only retrieve from the blockchain if not found in the database. The database is generated by synchronizing the information on the chain, so data authenticity is not compromised. The reasons for having metadata stored on-chain and in a database are; to reduce the high cost caused by continuously requesting data from the chain when the network demand is strong, and it is convenient for schedulers to process data faster.

Closing Thoughts

CESS adopts the R²S mechanism, which on the one hand, realizes the separation of consensus and storage, preventing the occurrence of “miners’ dilemma” and centralization. It also regularly checks consensus nodes’ honesty and scheduling functions through Trusted Execution Environment (TEE) technology to ensure that nodes provide the best possible service for the network through fair competition. The CESS decentralized cloud storage network built on Substrate (an open-source framework) is both EVM and WASM compatible, allowing dApps/apps to migrate seamlessly to the CESS network. CESS is dedicated to building a robust decentralized storage network with Web2 performance for crypto-native projects and traditional businesses of all sizes.

Join CESS

CESS website Twitter Telegram Discord Github Medium LinkedIn Instagram: cess_storage