In the personal property rights environment, all calculations are completed on the user's personal server (OOD), it is still a centralized system, and we can optimize concurrency and throughput like the central server of Web2. However, personal servers are only used to process self information. and the workload in central server of Web2 has been distributed actually to many personal servers of Web3, and the problems have been naturally alleviated.
Shared property rights are based on blockchain technology, and the process of blockchain consensus is serial; it is difficult to meet the high concurrency requirements in many Web2 application scenarios.
We can use multiple chains to improve the concurrent processing capability of shared property rights. In other words, we can optimize the design to disperse information in multiple rpath.
For example: a DAO organization manages the information of all its users.
Its structure based on RootState should be as follows:
All information of every user must be updated serially if there is only one chain. In fact, users are not related to each other in most time, we can update B without waiting for A.
Then, we try to start a chain for each user, manage the branch of each subpath with a consensus chain (rpath):
/users/user1
/users/user2
...
/users/userN
There is a small problem here. We also need to manage the user list jointly. In fact, the status of each user has reached a consensus, the rpath list maintained by this organization can express the current user list in most time. However, there is no strict consensus chain to maintain it, the rpath list in each node may be inconsistent for some abnormalities, and there is no historical record of updates. If your application is very sensitive to these issues, you need to design another rpath(/users/list) to maintain the user list, and you need to design carefully for the consistency between its content and the rpath list.
Now, does it feel familiar to server engineers in the Web2 era? Yes, it is actually similar to the divide-table and divide-database that are often used in Web2, but the form has changed. I will not go into specific details for lack of experience.
Concurrent computing and throughput optimization
In the personal property rights environment, all calculations are completed on the user's personal server (
OOD
), it is still a centralized system, and we can optimize concurrency and throughput like the central server ofWeb2
. However, personal servers are only used to processself
information. and the workload in central server ofWeb2
has been distributed actually to many personal servers ofWeb3
, and the problems have been naturally alleviated.Shared property rights are based on blockchain technology, and the process of blockchain consensus is serial; it is difficult to meet the high concurrency requirements in many
Web2
application scenarios.We can use multiple chains to improve the concurrent processing capability of shared property rights. In other words, we can optimize the design to disperse information in multiple
rpath
.For example: a
DAO
organization manages the information of all its users.Its structure based on
RootState
should be as follows:All information of every user must be updated serially if there is only one chain. In fact, users are not related to each other in most time, we can update
B
without waiting forA
.Then, we try to start a chain for each user, manage the branch of each subpath with a consensus chain (
rpath
):There is a small problem here. We also need to manage the user list jointly. In fact, the status of each user has reached a consensus, the
rpath
list maintained by this organization can express the current user list in most time. However, there is no strict consensus chain to maintain it, therpath
list in each node may be inconsistent for some abnormalities, and there is no historical record of updates. If your application is very sensitive to these issues, you need to design anotherrpath
(/users/list) to maintain the user list, and you need to design carefully for the consistency between its content and therpath
list.Now, does it feel familiar to server engineers in the
Web2
era? Yes, it is actually similar to thedivide-table
anddivide-database
that are often used inWeb2
, but the form has changed. I will not go into specific details for lack of experience.