DKG Governance
The DKG governance is split between different Substrate pallets that each handle a different aspect of the system.
Pallets
The DKG runtime is uses the following pallets which are central to how the protocol functions.
pallet-dkg-metadata
The metadata pallet tracks information about the DKG state. This includes the active and next authority sets and their authority set IDs, the active and next DKG public keys, thresholds, historical refreshes, and more. It’s main purpose is to provide on-chain information about the DKG and the next DKG for clients who are participating in the protocol.
The pallet houses a few sub-protocols, namely:
- The refresh protocol
- The misbehaviour and reputation protocol
One main importance of this pallet is to deterministically identify the best authorities for the next DKG’s authority set in order to signal participation to clients in the membership set. This ensures that all offchain clients see the same state of the world.
pallet-dkg-proposals
This pallet maintains the valid proposers and the first layer of the governance system: voting on proposals to be signed by the DKG. The valid proposers is superset of the current DKG authorities. Active DKG authorities are continuously rotated into the proposer set.
This pallet maintains a queue for pending proposals which the DKG authorities vote on and if the vote threshold
is met, the proposal is passed on to be handled by a type that implements the ProposalHandlerTrait. The
proposals meant to be processed by this pallet are primarily AnchorUpdateProposals but can be extended to
support any type of proposal that is meant to be submitted by the valid proposers.
pallet-dkg-proposal-handler
This pallet implements the ProposalHandlerTrait and accepts proposals through this handler system. In the
current incarnation, the pallet-dkg-proposals passes successfully passed unsigned proposals to this pallet
for queuing for eventual signing by the DKG. All unsigned proposals handled here are added to a queue which each
DKG client continues to poll from using a runtime API.
Off-chain, unsigned proposals move through the DKG’s threshold signature protocol and eventually, if successful, get re-submitted on-chain as signed proposals. The unsigned proposal records are removed and the signed proposals are stored in the pallet’s storage for inspection by any observing system, such as an oracle or relayer network.
This pallet represents the second stage in the governance protocol. That is, after the first layer of the governance system decides on which proposals to sign, this pallet helps expose those proposals and enable submission of them after successful threshold-signing.
Client
The DKG client (or gadget) is the main service that interfaces with the pallet system and overall governance protocol. It is responsible for listening to the chain and participating (if selected) in the DKG protocol.
dkg-gadget
The DKG gadget is an offchain service that executes the DKG protocols and stores data in off-chain storage for the on-chain system to fetch and post back on-chain. It also listens to changes in the proposal handler and metadata pallets in order to properly:
- Rotate keys
- Sign unsigned proposals
- Set and clear offchain storage
- Report misbehaviours.
We are always executing a DKG signing protocol for the current authority set and the DKG key generation protocol for next authority set if none has completed.
Note on Offchain workers
The DKG makes use of offchain workers to store data ready for on-chain submission.
If running a live chain as a validator, please add your sr25519 account keys to the node's local keystore
either by using the author_insertKey RPC or using the key subcommand
dkg-standalone-node key insert --key-type acco --scheme sr25519 --suri <path-secret-phrase>Key Type is
accoScheme is sr25519
Note For the standalone node the account being added to the keystore should be the Stash account used in staking not the Controller account