Hello everyone, last time we shared, we explained the relationship between block size and block generation time and expansion. We specifically explained how these two variables interact and restrict in the blockchain system. Today we will discuss in detail the relationship between these two variables in the DAG system, and how we deal with this problem in the design of Soteria DAG.
concurrent parent-child relationship
As we mentioned in the previous article, under the background of the BlockDAG block diagram, because there is no winner-take-all restriction, miners can mine in parallel and broadcast the mined blocks in a timely manner. The transmission of the network causes delays, so the broadcasts of other miners we can hear in any part of the network may also be different. But it doesn't matter, for the blocks we receive, we try our best to include them in our block graph. And the next new block we want to dig must refer to every unreferenced block (that is, leaf node) in our block graph. Burning Goose, you will find that we may receive some blocks like the picture below, their references are different, and they are all legal blocks dug by honest nodes. What's going on here? This is caused by the block size, transfer time and block time we talked about earlier.
Assume that the above state is the state observed by node B in the figure below. Then the reason why the parent link of each received block is different is because the information takes different time to propagate on the network: Suppose the network is divided into three propagation areas due to geographical or logical links, and the green area is sandwiched between the red ones. Between the blue area and the blue area, there is a certain delay in the transmission of information from the green area to the red or blue area, and the information transmitted between the blue and red area has to pass through the green area, so the delay is greater. For simplicity, we consider this cross-region latency to be twice the inter-region latency. Node A, Node B, and Node C generated block a, block b, and block c respectively (the parent links of these blocks are not discussed for the time being), and they immediately broadcast the block to all directions of the network. Node D in the red area and nodes E and F in the blue area will receive these blocks at different times. Because the network position, bandwidth, and delay of node ABC relative to node D and node E/F are different on the network, the time for them to receive the complete block abc is also different. So at a certain moment, node D only received block a and block b while block c is still on the way; node E/F only received block b and block c, and block a is still on the way . Node B is the closest node to the node that produced the block. Except for the block b generated by itself, all other blocks have also been received.
When nodes D, E, and F start digging the next block, according to the principle of "tolerance", they will lock the parent link of the new block on the blocks they just received, and then broadcast it immediately . That is, node D generates a block d linked to block a and block b, node B generates a block b' linked to blocks a, b, and c, and node E and node F respectively Block e and block f linked to blocks b and c are generated. This is exactly the state of the BlockDAG we saw earlier. Obviously, there cannot be any link between blocks a, b', e, f, that is to say, they are all of the same generation, or they are all brothers and sisters. Compared with the "one-child" policy in the previous blockchain structure, in the block diagram environment, there will be a situation of "more children, more blessings". We did not adjust the block size and block production speed, so we automatically expanded the capacity. The number of siblings reflects our ability to scale. Let's call it K for now. In order to describe K scientifically, we give the following expression: For any node, when it generates a block b at time t; and the maximum transmission delay of the network to the block is Dmax, that is, between any two nodes The time required to complete the transmission of a standard-sized block; then in the following interval:
[t-Dmax, t+Dmax]
The blocks generated in the entire system should be brothers and sisters of block B. This is very easy to understand: at time t, due to network transmission, all the blocks generated during the period [t-Dmax,t] have not been transmitted to this node, so these blocks will not be considered when B is generated. The parent node is used for linking. Similarly, the nodes that start mining during the period [t, t+Dmax] have not heard block B due to transmission delay, so the blocks generated by those nodes cannot regard B as the parent node. Link. Then, if the block generation speed of the system is r, then on average, the upper limit of the number of blocks generated during this period is:
(t+Dmax) - (t-Dmax)
——————————
r
that is
2Dmax
———
r
Therefore, capacity expansion is still restricted by network transmission delay and block generation speed, but this time, there are no previous restrictions. Are there really no such restrictions? Of course not. First of all, the above description is a very approximate result. For more rigorous results, you can refer to Chapter 4 of Phamtom's paper; more importantly, even rigorous results will have more restrictions in the environment of engineering implementation. Conditions, such as the processing time of the received block, the time of linking the block graph, and the verification time of the block. These times directly affect the linking characteristics of the block graph in actual operation. Therefore, the concurrent expansion parameters that can actually be operated may be an order of magnitude smaller than the theoretical value. From an engineering point of view, we adopted the method of inverting K according to the application scenario: first determine a required range of throughput, and then determine a Dmax according to the range of network transmission performance of the system operating environment, and then consider it on the basis of Dmax Add some software delays, and finally run the above parameters multiple times in the simulation system to get an optimized coefficient.
