Monday, May 10, 2021

Thinkium-Blue Paper 5.1 & 5.2

5 consensus protocol

In Thinkium system, there are three types of nodes in each chain: data nodes, consensus nodes and common nodes. The data node is responsible for the storage of all the data in its chain and the interaction between the chain and the chain. The main responsibility of the consensus node is the operation, packing and consensus of the chain, and the common node only carries the service. The figure below shows the relationship of different nodes between multiple chains.

https://preview.redd.it/lw5jdkavfey61.png?width=706&format=png&auto=webp&s=0c6cc19797bd178bfdd2d4ff8a83b88ea1340377

Each participating consensus node is randomly assigned, and will be re-selected as time goes by.

5.1 Committee selection

To counter the Sybil attack on unprivileged systems, we use a Proof of Equity (PoS) based election algorithm. Early blockchain projects such as Bitcoin and Ethereum used Workload Proof Consensus (PoW). Consensus participants compete for the bookkeeping right through the "mining" (that is, to carry out some specific complex calculations). Mining requires a lot of power and takes up a lot of computing time, but these resources do not contribute to improving the efficiency of the system. In fact, because the confirmation of a transaction requires the reception and verification of most nodes across the network, the time spent in broadcasting information on the network also increases as the number of nodes increases, and the efficiency will decrease.

In addition, if the consensus algorithm requires each transaction to consume bandwidth, computation, and storage resources for each participant, the performance bottleneck of the system will depend on the weakest participant in each dimension. In this case, the nodes participating in the consensus should only be the "super nodes", which form centralization in fact.

Therefore, we have chosen a consensus mechanism based on proof of interest (PoS). In the PoS mechanism, the consensus participants' billing rights depend on the assets they own.. In our consensus algorithm, consensus participants prove their rights by submitting a deposit. The system regularly selects a certain number of participants through a random algorithm, according to the proportion of the deposit to form a committee responsible for a period of time. In the multi-chain system, the committees of each chain can exist at the same time and run independently of each other since only the selected committee members need to participate in each block. As the number of nodes in the network increases, it is possible to support running more sub-chains at the same time to utilizing the resources of the nodes efficiently.

Compared with PoW, PoS consensus does not need to be excavated, which greatly reduces the threshold for participation in consensus and energy consumption, and is more likely to achieve true decentralization. On the other hand, unlike DPoS's super node, the committee is randomly elected, which guarantees fairness and gives everyone the power to participate in the block and get rewards, and also prevents the various problems caused by the monopoly of super code. Similar to PoW, the security of the PoS algorithm only needs to assume that most of the rights are not malicious and the network satisfies weak synchronization. The selection algorithm requiresthe following security attributes

• Assume that the proportion of equity in the honesty node among all participantsis δt . At least the proportion δᗉ of committee members elected in each election is honest. In addition, the algorithm should be fair because the probability that each participant is selected (roughly) is proportional to the number ofsharesinvested by the participants.

• Committee members should be mobile and unpredictable so that opponents cannot attack the system through corrosion committee members (assuming that corruption takes longer than the committee'slife).

In Thinkium, we implement the above properties through the following process. First, when the next committee needs to be selected, the sub-chain must send a singal on the main chain for all nodes are listening to the main chain.. The election of all chains is carried out in the main chain. Through the summary information on the main chain, the main chain can collect the election status of each chain and publish it in a unified manner. At the same time, random seeds are generated periodically on the main chain to ensure the randomness of each chain election.

Nodes that are willing to participate in the consensus need to register on the main chain by sending a special type of transaction. The transaction also stipulates the equity amount, which will be transferred to a specific share account and frozen, instructing the node to withdraw and withdraw the equity. After the main chain issues the election information, the consensus participants can see the election information in the main chain, and use the corresponding random seed and their private key to calculate the value of a verifiable random function to determine whether they are selected. When a node finds itself having the right to join a chain committee, it will join the chain's network firstly and send its own ID and verifiable random function proof, which will be recorded by the current committee. At the same time, new members of the committee need to prepare for participation in the consensus and join the committee's network. They also began to synchronize the state of the sub-chain. The received block and status can be verified by the abstract on the main chain.

The elected nodes will establish a small consensus network for communication within the committee. The owning of dedicated network reduces latency and bandwidth consumption for peer-to-peer communication and broadcast between committee members. On the other hand, if the set is incorrect, the network may be less stable and more vulnerable to attack. You need to make sure your network topology is robust and securely exchange node information through using encryption. At the beginning of the next era, the new committee should generate a new key, synchronize and update the current state of the chain, and establish a connection in the new consensus network.

The fairness of the election is crucial to the security of the system: if the attacker can occupy a majority of seats in a committee, there is no way for the committee to come out normally. On the one hand, in order to ensure that random seeds cannot be manipulated, each random seed is generated by a set of members of the committee through threshold signatures: This approach greatly increases the difficulty for an attacker to predict subsequent random seeds and prevent random seed generation, as compared to random seeds independently generated by blocker. On the other hand, we have designed incentives that make honest committee members willing to record new committee members, rather than seeking to retain their powers by destroying elections.

5.2 Committee’s consensus

We assume that there is a part of the synchronous communication model within the committee, in which there is a valid Byzantine fault-tolerant algorithm, and a tailor-made PBFT variant is designed for this purpose. The committee only accounts for a small portion of the entire network, and they will build a smaller network to reduce the delay of the broadcast, so they can get out of the block stably and efficiently. Due to the nature of the PBFT algorithm, when the nodes in the committee satisfy the weak synchronization hypothesis, the block algorithm can run safely when the malicious nodes accounts for less than 50% of the nodes. Therefore, under the premise of the security of the election algorithm, the activity, correctness and uniqueness of each committee can be guaranteed. In addition, our deposit and penalty mechanisms make it costly for members of the committee to do evil, which encouraging honest users to refrain from doing evil by reporting other people's malicious behavior.

Figure: Committee consensus.

The execution of nodes can be divided by rounds. Each round consists of three phases: proposal, preparation and confirmation (as shown in the pictured above). State transitions are driven by event. In order to keep the system active in the event of a network failure or malicious attack, the local clock may trigger a timeout.

Proposal stage: The person in charge of the committee broadcasts the proposed motion to other committee members. Preparation phase: After each committee member receives the suggested block, it broadcasts a message containing the signature of the block. If a timeout is triggered before the suggested block is received, the committee members sign and broadcast a special message to the other committee members (indicating that the leader is defective).

Confirmation phase: At the end of the preparation phase, each committee member signs and broadcasts a signature received during the preparation phase. Signature aggregation can be used to reduce the size of messages in the validation phase significantly.

Based on the messages received during the validation phase, each committee member can decide whether an agreement has been reached on the block and to broadcast the agreed block or empty block and the evidence of making such decision. Malicious node punishment. In the case of detecting a node with a definite misbehavior (for example, a node that sends a different message to a different node at the same stage), the round will be aborted by outputting an empty block. However, misbehaving nodes will be subject to a large number of economic penalties, which make this attack unsustainable. Optimization. If the number of signatures received during the preparation phase means that most honest committee members have received the same proposal block, committee members may reach an “early consensus”: members can use the signature to output the block as proof of the protocol before the validation phase (in different forms compared to conventional protocols). Please note that the node still needs to participate in the validation phase.

5.3 Safety analysis

https://preview.redd.it/ip6jm2xihey61.png?width=901&format=png&auto=webp&s=d5ba478a7a6a8a376ce6498595b85ed4ee717a0e


No comments:

Post a Comment