Some big updates to the cryptographic equivocation feature are being included in a new release that will go through testing next week. This is to address concerns about:
- Past equivocation on the Hub that has already been addressed via governance (e.g., Prop 818)
- Multiple valid chains with the same
chain-id, such as prior testnets, on which validators may have used their mainnet keys.
A feature has been added that does the following:
- For new consumer chains:
- Records the consumer chain block height at the time it enters the Hub’s security.
- Filters out equivocation evidence that occurred prior to that block height.
- For existing consumer chains:
- Records the consumer chain block height at a specified time:
- Neutron: block height
4552189 - Stride: block height
6375035
- Neutron: block height
- Filters out equivocation evidence that occurred prior to that block height.
- Records the consumer chain block height at a specified time:
In effect, this means equivocation on consumer chains prior to entering the Hub’s security will not be punished by the Hub. For existing consumer chains which are already within the Hub’s security, any equivocation prior to today will not be punished.
I had raised some concerns specifically about a past noble-1 testnet, and this feature removes that risk in a very tidy way, as any equivocation taking place prior to to mainnet noble-1 joining the Hub’s security cannot be punished by the Hub.
Going forward, it is Hub validators’ responsibility to use new keys for each consumer chain and especially to not reuse keys on testnet chains that have the same chain-id as one currently on mainnet.