View Change and Distributed Key Generation(DKG)
Last updated
Last updated
View Change : Periodically, the active set of miners and sharders is updated. This process is referred to as a view change.
Züs blockchain relies on a publicly verifiable random value calculated with each round of block generation. This is achieved by using distributed key generation (DKG) that provides the ability to recover a group signature using a t-of-n threshold signature scheme. That is, in order to defend against Byzantine and other faults, only a threshold number of signatures are required to reconstruct the group signature that everyone can verify and agree upon. The group signature is used as a seed to create a random number for each round and the signature for a given round is based on the random number from the previous round.
Züs uses the Joint-Feldman by Pedersen This protocol starts with n parties but eventually ends up with q parties, referred to as qualified parties. The qualification happens due to the nature of distributed key generation that can result in Byzantine condition. The original protocol suggests using complaints and revealing individual secret shares to narrow down the qualified set of parties that are all verified to have shared the secrets correctly. The protocol requires broadcasting on the order of O(n 2) messages for the complaints and revealing.
In addition to the verbosity of the protocol, the timing of those messages and the reliability of coordinating them across all the parties can be a challenge.
Züs uses a novel approach by using the blockchain itself to solve this problem. All the publicly available information is submitted as transactions to the blockchain; each of the n parties need to initially submit one transaction each on the blockchain with the public information of the protocol. After this,the parties will privately send the party specific information among themselves, which are of the order O(n²). However, there is no complaint or revealing. Instead, each party as part of distributing its secret shares to the others will collect digital signature of acknowledgement that they have received and verified their secret share against the public information already available on the blockchain. At the end of distributing the secrets to all the parties, each party ends up with either:
A digital signature verifying a valid distribution, or
no digital signature because the receiving party either did not provide one(Byzantine) or was not responsive (temporary network failure).
After some amount of trying to distribute the shares, eventually each party will publish another transaction on the blockchain with an array of either:
digital signatures confirming the receiving of valid secret shares, or
the secret share value and the corresponding party that did not provide or receive the secret share.
That is, the onus is on each party to submit this information to the blockchain. Any party that is not able to gather at least t confirmation signatures is automatically disqualified. For any party that received fewer than the threshold confirmations, their corresponding secret shares are revealed but they cannot be used to reconstruct the secret information of that party. The revealed secret share values can be used by honest parties that genuinely did not receive the secret shares at all or were given incorrect values, as they are now publicly available on the blockchain and verifiable.
Using the above logic, the qualified set can be deterministically computed by each party using the publicly verifiable information available on the blockchain. Hence, this design eliminates some of the complexities of identifying the qualified set with the original DKG protocol.
The view change process is divided into 5 phases: in the start phase, the incoming miners are selected; in the contribute phase, they calculate their public and private keys and write the public information to the blockchain; in the share phase, the miners distribute shares of the secret key to all miners; in the publish phase, the miners send their shares and signatures to the smart contract; finally, in the wait phase, the magic block is created for the next view change.
Start: During this phase, the smart contract gets the list of all miners who have registered. The list is sorted by stake and n miners are selected to become the incoming miners. If there are more than n miners in the list, only those with the most tokens staked join the set of miners.
Once the list is made, it is saved in the smart contract. This design allows miners who are not part of the current view change to request the list from the sharders through a REST API.
Contribute: Part of the incoming miners list specifies:
The maximum number of miners, n.
The threshold of signatures needed for the view change to be successful,k, which should be greater than t but less than n.
Threshold of signatures to verify a signature, t.
Each miner in the miners list uses the n and t parameters to create a miner public key (MPK), which is sent to the smart contract. Any miner who fails to send an MPK during the contribute period is removed from the incoming miners list. This is done because the MPK will be used to verify the signatures during the share phase and the share or signatures during the publish phase.
Note that there must be at least k signatures, or the process will fail and need to restart. This design provides some redundancy in case of an active set miner later failing to perform its duties. If the minimum amount of k miners are selected during the view change process, up to k − t miners could fail without halting block production.
Share: During this phase, the miners only communicate with each other. They use the MPKs they sent to the blockchain to verify the secret shares sent to them from the other miners for every miner in the incoming miners list and send them the share. When a miner receives a share, it uses the published MPK from the miner who sent the share to verify it. Once verified the miner will use its private key to sign a message and send it back to the original miner.The original miner collects the message and signature from all the other miners in the incoming miners list. If a miner doesn’t receive a signature it uses the secret share instead for that miner.
Publish: Every miner sends the collection of shares or signatures to the smart contract. The smart contract verifies the share and signatures are correct. If enough shares for one miner come in it is removed from the incoming miners list. Likewise, if a miner doesn’t publish the shares or signatures then it is also removed from the list.
Wait: At the beginning of this phase, a magic block is created for the next view change. Every miner uses the list on the magic block to determine the secret shares used for their personal private key for the verifiable random function (VRF) in the next view change.