One of the last open loops we haven't closed is how the emergency fallback mechanism gets triggered. When the chain stalls, due to the inability of the active DKG authorities to sign the next DKG public key , we must have a way to recover either with the active DKG key and authorities or by triggering an emergency keygen reset which effectively moves on without a proper rotation.
Let's consider the latter. When we trigger an emergency reset on the keygen mechanism, assume a new DKG protocol is executed successfully. The state of the active key and signature are erased and the active key is set to then be the new DKG key. In this event, one potential trigger mechanism is:
The fallback participants are the validators themselves, specifically the ecdsa (wdkg) keypair that we generate for each validator.
When the active validators (not authorities) execute a force emergency keygen, we can enforce (with slashing) that the validators must submit a signature of a vote, i.e. we would utilize their wdkg key to sign abi.encodePacked(vote).
Relayers would relay these signatures to the SignatureBridges in order to force rotate those contracts governors, i.e. our fallback resembles a multi-sig vote by the DKG authorities themselves (voters are bound by ProposerSetUpdate proposals).
Needed changes
We would add a method to Governable.sol that allows us to relay these signatures to the contract directly, further decentralizing the applications through this separation of signing and execution.
We would add a relayer service that exclusively handles this process (or tack it onto the "Governance Relayer"). This role would listen for signed ProposerSetUpdate proposals on the DKG chain and relay them to updateProposerSetData in a similar way to how the RefreshVote rotation protocol is handled.
We would need to trigger this signature generation by active validators once a stall is triggered.
We would need to add slashing to validators who don't vote if an outcome cannot be decided within some chosen interval of time.
(Aside: To an extent, more functionality like this separates the DKG networks like Tangle from the applications that they indirectly govern. Using the DKG in your application is permissionless (the DKG stays alive by sometimes executing emergency resets, the applications' userbase must relay the DKG protocol output in order to stay alive).)
Checklist
Functionality
DKG Work
[ ] Active proposers should watch for stalled chains in a worker service.
[ ] When stall is detected, active proposers should generate ECDSA signature of the encoded Vote object and submit it on-chain.
[ ] New pallet functionality to handle submission and storage of these signatures for the respective session with key events for watching/subscribing to.
Relayer work
[ ] Governance relayers (or a new ProposerSetUpdate relayer) should listen for the specific event when a vote signature is submitted.
[ ] These relayers should submit a TX to the update the proposer set on the Governable instances.
Smart contract work
[ ] We should make the signatures of Votes relayable, by simply providing signatures of a vote and ensure replay-ability is prevented across sessions.
[ ] We should consider making both the refresh + proposer set update executable in a single function so as to prevent the need for multiple txes.
Overview
One of the last open loops we haven't closed is how the emergency fallback mechanism gets triggered. When the chain stalls, due to the inability of the active DKG authorities to sign the next DKG public key , we must have a way to recover either with the active DKG key and authorities or by triggering an emergency keygen reset which effectively moves on without a proper rotation.
Let's consider the latter. When we trigger an emergency reset on the keygen mechanism, assume a new DKG protocol is executed successfully. The state of the active key and signature are erased and the active key is set to then be the new DKG key. In this event, one potential trigger mechanism is:
ecdsa(wdkg) keypair that we generate for each validator.wdkgkey is what is also used in theProposerSetUpdateproposal (here, (test of proposal execution).wdkgkey to signabi.encodePacked(vote).SignatureBridges in order to force rotate those contracts governors, i.e. our fallback resembles a multi-sig vote by the DKG authorities themselves (voters are bound byProposerSetUpdateproposals).Needed changes
Governable.solthat allows us to relay these signatures to the contract directly, further decentralizing the applications through this separation of signing and execution.ProposerSetUpdateproposals on the DKG chain and relay them toupdateProposerSetDatain a similar way to how theRefreshVoterotation protocol is handled.(Aside: To an extent, more functionality like this separates the DKG networks like Tangle from the applications that they indirectly govern. Using the DKG in your application is permissionless (the DKG stays alive by sometimes executing emergency resets, the applications' userbase must relay the DKG protocol output in order to stay alive).)
Checklist
Functionality
DKG Work
Voteobject and submit it on-chain.Relayer work
ProposerSetUpdaterelayer) should listen for the specific event when a vote signature is submitted.Governableinstances.Smart contract work
Votes relayable, by simply providing signatures of a vote and ensure replay-ability is prevented across sessions.