Here is the translated text while preserving the original Markdown format:

For any blockchain project, the consensus layer based on blockchain is the most important underlying architecture. The design of the consensus layer directly determines the overall network's efficiency, security, decentralization, and other issues. The rise of many new public chains today is largely due to the overflow of traffic caused by Ethereum's insufficient chain capacity after the DeFi Summer application explosion.

Compared to a purely public chain, a storage public chain, while being a more specialized functional network, has requirements for data processing efficiency that are no less than those of a general public chain. The reason for this is that many public chains, in pursuit of efficiency, often use the chain merely as a place for final state confirmation, executing more complex content off-chain.

As a foundational infrastructure for Web 3.0, the decentralized cloud storage network CESS (Cumulus Encrypted Storage System) adheres to the principle of decentralization from the very beginning of its design. It strives to meet the requirements of "information on-chain" as much as possible and utilizes efficient on-chain processing to avoid the inefficiencies brought about by decentralization, achieving a good balance between "distribution" and "efficiency."

1. Random Selection of Rotating Consensus Nodes Mechanism (R²S)

In order to improve on-chain transaction processing efficiency while achieving decentralization of nodes, CESS employs an innovative random selection of rotating consensus nodes mechanism (R²S) to facilitate block packaging and other on-chain transactions. As can be seen from the name, the nodes completing on-chain consensus in this mechanism are rotating, meaning they change over time. On the other hand, the so-called "rotation" is also "random" in selection; literally, within a time window, a certain number of rotating nodes will be responsible for maintaining consensus, and the randomness of selection ensures a degree of decentralization.

However, the real R²S is not as simple as it seems.

1.1 How to Achieve "Random" and "Rotation"

In fact, the most important point of blockchain is the consensus issue, but before explaining the R²S consensus mechanism, it is necessary to introduce the node-related issues within this mechanism.

The R²S mechanism allows all users who wish to become node operators to freely join the candidate nodes. However, within each time window (for example, every 10,000 blocks), only 11 formal rotating nodes are selected to participate in block production. The candidate nodes that do not participate in block production can also prove their working capabilities by participating in the data preprocessing process, thus participating in the selection of formal rotating nodes for the next round. In this process, the network will conduct reputation scoring for each node. If a node engages in behavior that harms the overall interests of the network during its work, its score will be reduced. When the score falls below a certain baseline, that node will be unable to compete for candidate node status.

To explain briefly, the data uploaded by users to CESS needs to undergo a round of data preprocessing before being allocated to nodes for storage. Preprocessing includes processes such as data sharding, encryption, and redundancy. We will present the specific content in the subsequent storage process.

Let’s take a complete look at the operation process of the mechanism: first, the network randomly selects 11 rotating nodes from all candidate nodes to complete block production and other consensus maintenance tasks within a fixed time window, while candidate nodes participate in the data preprocessing process to prove their working capabilities. During the time the rotating nodes are on duty, the network will randomly select another 11 nodes from the eligible candidate nodes as the formal rotating nodes for consensus maintenance in the next time window, and so on.

In this process, if individual formal nodes engage in malicious behavior or fail to meet network requirements, leading to forced offline status, the network will randomly select nodes from the candidate nodes to fill in until the duty for that time window is completed. Therefore, for consensus node operators, even if they are merely candidate nodes, they need to maintain continuous contributions to the network, which greatly increases the possibility of earning rewards.

1.2 Byzantine Fault Tolerance and Verifiable Random Functions

After understanding the specific mechanisms for node entry and exit, the next core issue of blockchain is: how to ensure the accuracy of on-chain data under the premise of decentralization. In this regard, CESS chooses to adopt a more secure Byzantine fault tolerance and verifiable random functions to ensure the security of consensus.

1.2.1 Byzantine Fault Tolerance

CESS draws on the PBFT consensus algorithm, introducing threshold signature algorithms and collector roles to implement a highly available Byzantine fault-tolerant consensus algorithm. This algorithm ensures that consensus can still be reached on-chain even when malicious nodes appear in the network.

The 11 consensus nodes on duty in this algorithm can be divided into primary nodes and secondary nodes, with secondary nodes including forwarding nodes and collecting nodes based on different tasks. Each round of the consensus process will have a primary node, which, upon receiving requests from clients, will package transactions into blocks and send them to all secondary nodes. Then, forwarding nodes will confirm and sign messages and forward them to collecting nodes. Collecting nodes will aggregate all collected messages into a signed message through the threshold signature mechanism and send it to all other nodes. Next, the process of forwarding and collecting will continue until the confirmation message is returned to the client. It is worth noting that the collecting nodes for two rounds can be designated as the same node or different nodes. The premise of ensuring the security and liveness of this algorithm is also based on the assumption that the number of Byzantine nodes in the system does not exceed 1/3 of the total number of nodes in the system. When the total number of nodes is N, at most f Byzantine faulty (traitor) nodes can be accommodated, requiring N to be greater than or equal to 3f + 1.

1.2.2 Verifiable Random Functions

Unlike most public chains, the consensus nodes of CESS are generated through random selection, which means there are higher requirements for the network's ability to respond to changes. In order to ensure security as much as possible in such a context, CESS adopts a model of "randomly selecting several consensus nodes from candidate consensus nodes, and then collaboratively packaging transactions through the consensus algorithm," which enhances the randomness and unpredictability of node elections while improving the security of the blockchain.

Each candidate consensus node possesses a public-private key pair. During each round of time window elections for on-duty consensus nodes, each candidate consensus node calculates the hash random output using the following formula.

R=VRF_Hash(SK, Seed)

P=VRF_Proof(SK, Seed)

Where SK is the node's private key, and Seed is a piece of field information from a block on the CESS chain that cannot be predicted in advance. R is the hash random output, and P is the hash proof.

Through the above steps, verifiers can easily verify that these two values are indeed produced by the node that possesses them.

R=VRF_P2H(P)

VRF_Verify(PK, Seed, P)

Where PK is the public key of the node being verified.

At this point, the 11 nodes with the smallest hash random output can be selected as the on-duty consensus nodes. If more than 11 nodes are selected, they will be filtered based on their reputation scores.

1.3 Admission and Exit

Although CESS does not set overly strict preconditions for node entry, it still requires meeting the basic operational indicators and resource contribution indicators necessary for network operation, as well as staking a certain amount of CESS tokens to participate, preventing node malfeasance. Once a node has completed the staking of CESS tokens, it can participate in the aforementioned process. When a node wishes to exit, the network will determine whether to fully refund the staked tokens based on the node's score during its operation. Theoretically, as long as the node works normally and does not experience long periods of downtime or engage in malicious behavior, the network will fully refund the staked tokens.

This admission mechanism can prevent Sybil attacks and enhance consensus security.

2. What Are the Advantages of the R²S Mechanism

From the perspective of mechanism design alone, R²S is somewhat complex, but the CESS team has specific considerations for storage public chains when designing this model.

2.1 Solving the "Miner Dilemma" and Avoiding Monopoly

The "miner dilemma" refers to the situation in storage networks where miners are more inclined to store data that can generate revenue rather than block history (which can be understood as unwilling to establish full nodes), only ensuring network synchronization by retrieving data from a few full nodes or joining mining pools, leading to excessive centralization of full nodes. CESS uses R²S to achieve a separation of consensus and storage, ensuring that the storage of block history is more decentralized while also preventing large miners from becoming overly centralized, which would be detrimental to the overall development of the network.

2.2 Significantly Improving Efficiency Under Decentralized Frameworks

If consensus is maintained solely by 11 nodes, it would improve efficiency but make the network extremely centralized, like a consortium chain. To achieve decentralization within this efficient framework, CESS has established a mechanism for randomly selecting nodes to participate in maintaining consensus in each round. As long as the node requirements are met, there is an opportunity to participate in block production, effectively addressing the issue of centralization.

2.3 Achieving On-Chain Transaction Processing

The on-chain data of CESS includes not only the confirmation of transactions and contracts but also the "location" information of user-uploaded data. In other words, CESS has successfully achieved the on-chain storage of metadata for the content stored. While many projects currently prefer to process some data off-chain to improve on-chain efficiency, such solutions require many guarantee mechanisms for security and are often a necessity due to low on-chain processing efficiency. CESS, due to its efficient on-chain transaction processing, can achieve the on-chain storage of metadata, allowing for direct addressing of data storage through on-chain data, thus ensuring the authenticity of the data.

However, it should be noted that in actual operations, in order to prioritize storage network efficiency, nodes will maintain a database of metadata, and addressing will first start from this database. Only when data cannot be found will it choose to retrieve data from the chain. This database is generated by synchronizing on-chain information, essentially not undermining the characteristic of authenticity.

As for why consensus nodes need to save the same data both on-chain and off-chain, it is to reduce the high costs caused by continuously requesting data from the chain during periods of high network demand, and also to facilitate other scheduling parties to process user data more quickly.

*3. Summary

Overall, CESS adopts the R²S mechanism to achieve a separation of consensus and storage, preventing the emergence of the "miner dilemma" and monopolies; on the other hand, it ensures that nodes provide the best possible services to the network through fair competition by regularly checking the honesty and scheduling functions of consensus nodes using Trusted Execution Environment (TEE) technology. The CESS decentralized cloud storage network, developed based on the Substrate open-source framework, not only supports WASM but will also be compatible with EVM smart contracts in the future. This is not only to facilitate developers in establishing a native CESS ecosystem, providing a place for many projects with high data interaction needs; it also allows many applications to seamlessly migrate to CESS, paving the way for rapid development in the early stages.