To resist the Sybil attack against the permissionless system, we use a proof-of-stake based election algorithm.
The following security properties are desirable for the selection algorithm.
• Assuming δ0 honest majority (of stake) among all participants, at least δ1-proportion of the committee members elected in each election are honest except with negligible probability. Furthermore, the algorithm should be fair in the sense that the probability of each participant being chosen is (roughly) proportional to the amount of stake committed by the participant.
• The committee members should be fluid and unpredictable, so that the adversary cannot attack the system by corrupting committee members (assuming corruption takes longer than the life span of a committee).
In Thinkium, we achieve the above properties through the following process. First, before the election, since only the root chain is listened to by all nodes and the chains are not synchronized, a transaction chain has to put a signal on the root chain when it needs to elect the next committee. The election will use the next seed after the signal shows up on the root chain.
Next, the election process is managed by the root chain. In particular, the randomness used in the election is provided by the random seed generated in the root chain CR. The committee of the root chain generates a random seed periodically, which is included in a block of CR. Our current implementation generates random seeds using DFIN- ITY’s random beacon protocol, based on BLS thresh- old signature.
In addition, nodes willing to participate in the consen- sus need to register on the root chain by sending a special type of transaction. The transaction also specifies the amount of the stake, which will be transferred to a specific stake account and be frozen until the node quits and withdraws the stake. These nodes then monitor the election signals in the root chain. When a node sees an election signal and the next seed, with its secret key, it can compute whether it is elected to the next committee of the chain that sent the signal.
Once the committee selection is completed, nodes elected to a transaction chain will join the network of the chain and start receiving the blocks of the chain. They also start to synchronize the state of the transaction chain. The received blocks and the state can all be verified using the digests on the root chain. Each node sends an “elected” transaction containing its public key and a proof that it has been elected, so that the current committee and the other elected members are notified.
The elected nodes will set up a small consensus net- work that will be used for the communication within the committee. Having a dedicated network reduces the delay and bandwidth consumption of both point-to-point communications and broadcasts among committee members. On the other hand, if not set up properly, the network may be less stable and more vulnerable to attacks.
Overview of committee consensus.
be ensured that the network topology is robust and node information is exchanged securely using encryption.
By the time the next epoch begins, the new commit- tee should have generated the keys for threshold signature (the public key should have been written to a block); have synchronized and updated the current state of the chain; and have established connections in the new consensus network.