Gravity: Consider enforcing validation expiry on-chain

[code423n4]

Handle

hickuphh3

Vulnerability details

Impact

"There must be a validator set update made on the Ethereum contract by calling the updateValset() method at least once every Cosmos unbonding period (usually 2 weeks). This is because if there has not been an update for longer than the unbonding period, the validator set stored by the Ethereum contract could contain validators who cannot be slashed for misbehavior."

This condition seems important enough to warrant its enforcement on-chain, where expiry of the current validator set should be checked in submitBatch() or submitLogicCall().

Recommended Mitigation Steps

Have a variable to keep track of the timestamp of the last updateValset() call, and another (configurable?) variable for the valid duration length of the validator set.

uint256 valSetLastUpdated;
// TODO: create setter for valSetValidityLength
// make it configurable by validators, set only in constructor (immutable) etc.
uint256 valSetValidityLength;

[jkilpatr]

This has been much discussed in previous design audits. You can enforce an expiry of the validator set, but it's a road to nowhere.

If the validator set expires who can update it? The same validator set we're trying to limit by forcing expiry. There's no other authority we can reach out to (without inserting some sort of backdoor or hardcoded multisig) to constrain the validator set in the bridge.

This is why we enforce generation of validator sets on the Cosmos side and ensure they are easy and permissionless to relay.

not a bug.

[albertchon]

Agreed, perhaps some ADR's would be good in the future to publish though.

Although rather than expiry I think something like this should be considered @jkilpatr

[loudoguno]

reopening as per judges assessment as "primary issue" on findings sheet