This article will introduce the technical implementation of fast and strong consistency of the DFINITY network. The core keywords are: threshold group, threshold relay, probabilistic slot consensus, and threshold relay.
Background
DFINITY uses the PoS consensus mechanism. Participating in the network requires a certain amount of stake (i.e. DFINITY tokens) as a deposit. All nodes are equal, and the only way to increase returns is to add more nodes to the network. It is important to emphasize that all DFINITY nodes have the same deposit, and there is no additional benefit from paying more deposit.
Part of the advantage of PoS is that all nodes are known to the platform, so the platform can call nodes to perform certain functions and expect them to be online. If the node being called is offline, the node may lose part of the deposit.
Because we know who is participating in the network, and assuming that almost all nodes are online, we can randomly assign tasks to nodes with a high degree of confidence that these tasks will be completed. This is also the basis of DFINITY.
Threshold Group
Committee
Threshold groups are a very important concept in the entire consensus generation process of DFINITY. Threshold groups allow us to avoid the situation where there is only a single decision maker and are the core of DFINITY. At any time, there is an active pool of threshold groups in the network. Each threshold group is randomly sampled from all nodes connected to the network. A node may be included in multiple threshold groups at the same time.
All nodes in a threshold group work together to create randomness; a new threshold group is selected from the threshold group pool in each round.
Threshold groups are randomly selected in advance and put into the pool. As shown in the figure below, during time period 1, the threshold group for time period 2 is selected. At the end of time period 1, the threshold group for that time period is disbanded and the threshold group for time period 2 begins to operate. The same process repeats indefinitely.
Threshold relay
Threshold Relay
DFINITY’s randomness is generated by a threshold-relayed verifiable random function. Imagine you’re playing a poker game — you need to be able to verify that the dealer cannot predict or manipulate the cards that come out of the deck. This is why you shuffle the deck in public view. Shuffling the deck is a verifiable random function that works on a network of untrusted nodes — the poker players.
To create a threshold relay, we use threshold encryption. However, first let's understand public key encryption. Imagine that your door has two keys, one key to lock the door, and one key to open the door. You can give the key to lock the door to anyone, who cares if someone else can lock your door? The important thing is that only you can open the door.
Digital signatures in public key cryptography are basically this, but more abstract. You have two keys, one that can sign a piece of data, and another that can be used to verify the signature. If other people can verify your signature on a piece of data, that's a good thing, provided you're the only one who could have created that signature. This is where "public key private key cryptography" comes in. The signing key must be private.
Threshold encryption is basically the same principle, except for one difference: in threshold encryption, the private key or signing key is divided into multiple shares, each of which can be used to create a signature. Once a threshold ratio of signature shares are aggregated, they create a complete digital signature that can be verified using the public key.
If there is not enough share to create a complete digital signature, it cannot be verified. In the actual implementation of DFINITY, we only need to make the aggregation ratio reach a majority (51%). Here we need to know: each threshold group has a public key, and each group member has a share of the private key.
Below is the process of threshold signature. A very nice feature of threshold signature is that no matter which signatures are aggregated to create a complete signature, the final signature is the same.
Then we will get a bunch of digital signatures, which is a good source of randomness if no one knows the content in advance. We will use this signature as a random beacon later.
So how is the random beacon generated? We start with a random source, which is used to select a threshold group, and the threshold group members sign the randomness (used to select the threshold group).
That threshold signature (remember we only need a 51% threshold, and no threshold group member can influence the signature here) is used to select the next threshold group. This process continues indefinitely.
Random Sorting — Probabilistic Slot Consensus
Probabilistic Slot Consensus
Because the protocol has a list of all nodes connected to the network, it can take this list and the random beacon as input and output a randomly sorted list. This random sorting needs to be done through probabilistic card slot consensus.
The nodes at the top are considered to have a higher priority (rank). The priority affects the probability of a node adding a block to the chain, the higher the priority, the greater the probability.
Nodes can do this themselves and prioritize blocks before creating and broadcasting them. This saves computational and network resources, since in practice only a few (e.g. five) nodes may have to create and broadcast a block.
Block signing
In the DFINITY network, threshold groups for creating randomness also have the function of signing blocks.
Each threshold group member follows the same rules: they receive a block and if it is invalid, they discard it. If it is valid, they check its priority.
If it has a lower priority than a block they received previously, they discard it. If it has a higher priority, they sign it with their private key share and then broadcast the block and the signed share.
Once a block has collected the necessary number of signature shares to produce a complete, verifiable signature, it is considered "notarized" and the block is added to the chain.
The following is the entire block process:
DFINITY’s efficient block confirmation
Based on the use of threshold relay verifiable random functions, the block confirmation time of the DFINITY network is only two blocks, the confirmation time can be as low as 2.5 seconds, and the transaction processing volume per second is about 50. In general, the speed of block confirmation is indeed very fast, and we must also see the huge role played by VRF in it.
How to Create a Threshold Group
1) New clients joining the network are randomly assigned to different groups through the VRF algorithm.
2) Initialize the parameters of the threshold group (including group size, threshold, etc.).
3) After initialization is completed, the public key of the successfully created group is registered to the network.
4) The creation of threshold groups is decoupled from the blockchain business process, so they can be executed in parallel. As shown in the figure, we create red and green groups at the same time.
5) Newly added threshold groups and clients (or miners) need to wait for 2 EPOCH cycles before they can be activated.
How to choose the appropriate Epoch length: To ensure correctness, an Epoch must contain more blocks than a chain fork. However, since lightweight clients only save the block header information of key frames, for efficiency reasons, the epoch needs to be defined as long as possible, for example, one week.
Probabilistic slot protocol - ensuring block generation and avoiding forks
The introduction of the probabilistic slot protocol in the threshold signature relay structure can ensure that miners in the network always produce blocks on the optimal main chain. At the same time, combined with the VRF algorithm, high consistency and efficient block confirmation time are achieved.
The block generation process for each h height is as follows:
1) Sort the processes of the current height threshold group by the VRF algorithm.
2) Divide the sorted processes into different slots and mark them as the priority order within the system.
3) Score the processes in different slots and mark their weights.
4) DFINITY also introduces a timeout-based mechanism, which is how long to wait for the first selected process. If no block is generated, the next process will execute the block.
As shown in the figure, a complete block generation process: ① Random sorting; ② Grouping (slots); ③ Scoring; ④ Select the process with the highest score to package the block and broadcast it; ⑤ Threshold group relay, continue to search for the chain with the highest score over and over again.
left questions
The threshold relay structure and probabilistic slot protocol can achieve efficient block generation and extremely low probability of chain forks. However, we still encounter attacks attempted by malicious actors in the network, such as the following two situations:
1) Selfish mining attack: Malicious adversaries will selectively retain the mined blocks and gradually release them, gaining the advantage of controlling transactions compared to honest nodes; at the same time, selfish mining attacks increase the number of confirmations required to achieve final consistency.
2) Nothing at Stake: A malicious adversary only needs to be lucky enough to be selected as a series 0 slot (i.e., highest priority), then it can vote on all forks at any time and create forks from height h onwards and perform a replay attack.
The DFINITY network proposes a solution:
The core idea is to introduce a notary. The notary’s signature must exist at the current height. In this way, if the block is released late, the notary’s signature will not be obtained and the block will be deemed invalid.
Notary mode block production process
In order to solve the two potential threats, we introduced a notary to sign the block. The analysis of the block principle is as follows:
1) After the current height h receives the threshold signature of the previous group, the group members start their own timers and collect transaction information within BLOCK_TIME (without processing, note: DFINITY does not rely on strict clock synchronization).
2) While waiting for BLOCK_TIME, the probabilistic slot protocol scores the processes and selects the packaged processes.
3) After the BLOCK_TIME, i.e. the 5s waiting time, is up, two judgments are made: ① whether the chain with the highest score has been scored; ② whether the block is valid and the slot is selected as the process responsible for packaging; ③ the notary verifies the block, and the process broadcasts the shard of the threshold group signature of the block.
When will the signing action be terminated? Once the threshold is reached and the group signature of the current height is combined, the signature shard of the current height will no longer be signed.
A few conclusions:
1) Under normal network operation, if BLOCK_TIME is set large enough considering network synchronization, each group member will only prioritize the chain with the highest score.
2) The notary group will only certify the blocks representing the chain with the highest score.
3) This approach can prevent forks and thus achieve final consistency quickly.
Solving the same score problem
A process in slot 0 controlled by a malicious adversary could broadcast a large number of different versions of its blocks into DOS. Although this malicious process will be quickly expelled from the network due to Byzantine behavior, how can we prevent it from happening in the first place?
Solution: If a process finds a block with the same highest score, it is forwarded only to nodes that have not yet detected the same score. If a group member finds a block with the same highest score, it does not sign it, but starts signing the next highest scoring block from a different slot.
summary
Through the overall architectural design, the DFINITY network provides the ability to efficiently produce blocks, and any malicious behavior will be ignored by the network and punished by the notary.
Ideally, the DFINITY network only requires 2 blocks and threshold group relays to achieve final consistency, which is a huge advantage over competing blockchain platforms. When BLOCK_TIME is set to 5 seconds, the average confirmation time is only 7.5 seconds.
DFINITY’s Bronze release has significant performance advantages over first-generation (Bitcoin) and second-generation (Ethereum) blockchain technologies in terms of block time, transaction confirmation time, and fuel consumption.
question
Question: The threshold group for time period 2 is selected during time period 1. In this case, will the members of the threshold group for time period 2 be vulnerable to DDOS attacks?
Answer: The answer is no. Because in DFINITY, these members are hidden. The platform selects these members, but no one knows who they are.
Question: When creating BLS keys, communication is a bottleneck. How many nodes are in a DFINITY threshold group? How to improve this problem?
Answer: 400 nodes in a threshold group. Communication is expensive, but not expensive enough to be a problem we need to solve.
Question: What if a threshold group member discloses his private key?
Answer: Because we need a certain threshold (51%) of private key shares to reach consensus, the leakage of one share is not a problem.
Question: How many nodes are selected to initiate a block?
Answer: The answer is 0. Each node can be selected to initiate a block. The specific probability is determined by the random sorting algorithm mentioned above. The higher the priority, the higher the probability. If a block is initiated, there are about 5 nodes that actually implement it.
IC content you care about
Technology Progress | Project Information | Global Activities
Collect and follow IC Binance Channel
Get the latest news