To describe in more detail — during the development of UChain public chain, we found that the original proposed RPCA consensus algorithm has many shortcomings as followings:

(1) The practical operation of RPCA generates a block in a few seconds, which is not good enough to support the high-frequency transaction demand of UChain in sharing economy enterprise use-cases.

(2) The verification node of RPCA receives the transaction to be verified and stores it locally, and at the same time, the newly arrived transaction in the current round of consensus process needs to wait, and then confirms it in the next consensus. This verification process is cumbersome and easy to fork.

(3) The RPCA active trust node sends the proposal. The trust node list is a subset of the verification pool, and the trust node is derived from the verification pool. The collection of things in the account is completely biased towards transaction, not loosely coupled, thus future flexibility and scalability is limited.

(4) RPCA is more suitable for Class B services between centralized organizations than for complex scenarios at the consumer end.

Based on these reasons, the core team decided to develop UChain’s new consensus mechanism, UPoS, as we found this best met the performance requirements of the Sharing Economy 2.0, and enabled user governance. The core idea behind this new mechanism is that all users who hold UCN tokens have the voting rights to select the network’s nodes via a continuous voting manner.

The UChain blockchain is theoretically designed to produce one block every 0.5 seconds, and at a certain point in time, only one block producer (node) will be authorized to produce the block. If it is not generated within the predetermined time, the block will be skipped. When one or more blocks are skipped, the blockchain will have an interval of 0.5 seconds or more, which is an infrequent event and does not affect the entire blockchain production process.

When UChain performs block production, it produces 126 blocks in a round (a total of 21 nodes, each producing 6 blocks). Before the start of each round, 21 different block producers are selected based on UChain user's voting results. The production order of the selected producers are arranged in a sequence agreed by the producers of 15 or more (the process is automatically completed by the program). If a producer misses a block for various reasons (such as network latency, system bugs, etc.) and has not produced any blocks in the past 24 hours, they will be temporarily kicked out of the block production queue until the producer informs the network that it intends to resume creating blocks. By eliminating unstable and unreliable production nodes, the number of missing blocks is minimised, ensuring a safe and efficient operation of the network.

To some extent, there will be no fork scenario under UPoS because the relationship between the nodes of the UChain blockchain is a peer-to-peer collaboration rather than competitive during the production process. If a fork occurs, the consensus program will automatically switch to the longest chain. The working principle is that under the UPoS consensus mechanism, the new block addition speed of the forked chain is positively correlated with the number of producers in the chain. That is to say, the blockchain fork with more producers will grow much faster than the rest, because the less blocks will be skipped on the longer chain with more producers present. In addition, a block producer is not allowed to produce blocks on both forks at the same time, and if the system finds that the block producer is doing so, they will be automatically banned from the network. Digital signatures and timestamps of each block by the block producer will be used for system troubleshooting.

By requiring all producers to sign all blocks, the Byzantine fault tolerance mechanism was added as long as no producers sign two blocks with the same timestamp or the same block height. Once 15 producers have signed a block, the block is considered irreversible. If a Byzantine producer signs two blocks of the same time stamp or the same block height, the system will record the cryptographic evidence of its action. In this model, an irreversible consensus should be reached within 1 second.