Context
We have been seeing operational issues with the current Shuttermint-based DKG coordination layer. The main pain points are around keyper liveness, validator set transitions, eon/config synchronization, and recovery when a DKG or config transition gets stuck.
One option is to simplify Shuttermint by running it in dev mode, avoiding validator set transitions. This may be easier as a short-term mitigation, but it still leaves us with a separate coordination chain and separate state that can drift from the canonical chain.
As a longer-term alternative, we discussed moving DKG coordination to Gnosis. The idea is to use Gnosis as the durable coordination/log layer for DKG messages and potentially also use it as the coordination layer for Ethereum deployments, instead of running the DKG directly on Ethereum.
Before committing to this direction, we need to benchmark whether the numbers work for current and larger keyper sets. If Gnosis is cheap and reliable enough, we can proceed with a Gnosis-based implementation. If not, we should revisit alternatives such as simplified Shuttermint, a private chain, or using p2p for DKG messages.
Discussed Options
- Run DKG coordination on Gnosis.
- Use Gnosis as the coordination layer for Ethereum as well, instead of running DKG directly on Ethereum.
- Use p2p for DKG messages, though this may not remove the need for a canonical log.
- Use a private chain.
- Run Shuttermint in dev mode, avoiding validator set transitions.
What To Check
- Cost per DKG on Gnosis for current and larger keyper sets.
- Whether Gnosis is viable as the coordination chain for Ethereum deployments.
- Whether Ethereum direct costs are too high.
- Whether blob data materially changes the Ethereum cost estimate.
Expected Outcome
If the Gnosis numbers hold, implement Gnosis-based DKG coordination. If they do not, revisit the other options discussed above.
Context
We have been seeing operational issues with the current Shuttermint-based DKG coordination layer. The main pain points are around keyper liveness, validator set transitions, eon/config synchronization, and recovery when a DKG or config transition gets stuck.
One option is to simplify Shuttermint by running it in dev mode, avoiding validator set transitions. This may be easier as a short-term mitigation, but it still leaves us with a separate coordination chain and separate state that can drift from the canonical chain.
As a longer-term alternative, we discussed moving DKG coordination to Gnosis. The idea is to use Gnosis as the durable coordination/log layer for DKG messages and potentially also use it as the coordination layer for Ethereum deployments, instead of running the DKG directly on Ethereum.
Before committing to this direction, we need to benchmark whether the numbers work for current and larger keyper sets. If Gnosis is cheap and reliable enough, we can proceed with a Gnosis-based implementation. If not, we should revisit alternatives such as simplified Shuttermint, a private chain, or using p2p for DKG messages.
Discussed Options
What To Check
Expected Outcome
If the Gnosis numbers hold, implement Gnosis-based DKG coordination. If they do not, revisit the other options discussed above.