UChain — Updated Information on Technology Development & Testnet
Dear UChain Community,
In our previous weekly reports, we introduced our updated development progress of the UChain blockchain in detail. At the same time, the project team has further conducted relevant research and expert interviews to explore the practical technical needs and pain points of blockchain dApps in the sharing economy. Additionally, the team has dove deeper and rolled up their sleeves in evaluating and assessing the newest developments in blockchain technology. Based on a comprehensive conclusion of these insights, the core team has made a decision to perform an upgrade on the technical architecture featured in our initial plan with the following adjustments:
1. Some of the core code will be rewritten in C++ , increasing TPS, and with an embedded language it can provide a better system development support.
2. Switching from “Account Balance Model” to “UTXO Model”
After detailed technical analysis and research in the early stages, it is feasible to implement an effective digital identity system with UTXO. With more and more blockchain’ turning back to the UTXO model, it can be considered as an independent data record, whilst having great transaction verification speed which is achieved through parallelism, in terms of performance and reducing used storage space at the same time.
3. User account system UID, adding user credit (score, rating), equity (voting, community governance, node application).
4. The consensus mechanism is switching from RPCA to UPoS (User Proof of Stake).
5. The main encryption algorithm has been switched from the secp256k1-zkp version to the stable version of secp256k1
In general, we went from basing our technology off of a Ripple-based core to proprietary technology designed by our own team.
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.
The adjustments of the technical development plan is based on the thorough analysis on all mainstream and evolving technologies currently in the industry. Only by staying ahead of the curve, will UChain's technical solutions truly bring mass adoption of blockchain technology to the general public.
The detailed upgrade timeline would be planned as followed:
(1) The core underlying code modules rewriting in C++ is expected to take 14 working days;
(2) The account balance model changing to UTXO is expected to take 10 working days;
(3) Add a user digital identity UID module is expected to take 12 working days;
(4) Reconstruction and implementation of the consensus algorithm is expected to take 18 working days;
(5) Encryption algorithm upgrade and other changes are expected to take 5 working days.
Taking all of this into consideration, the core team has made the decision to slightly delay the release of our Testnet to the month of October, and subsequently our Mainnet, to allow for these changes to be fully implemented and internally tested. We will continue to update our community with the weekly / bi-weekly updates on various developments, team news, and community updates.
As always, we would like to thank our community for their continuous understanding and support.
Ian Yu,
Founder and CEO,
UChain
