No trusting period or attestation expiry time check in Ethereum

[dalmirel]

Involved artifacts

• x/qgb/abci.go
• QuantumGravityBridge.sol

Description

The EndBlocker in the QGB module has a function to remove old attestations. Attestations are considered expired if they are older than the AttestationExpiryTime, which is currently set to the consensus unbonding period (3 weeks) - trusted period.

• The Solidity contract doesn't verify the attestation's expiry time, nor does the QGB module keep track of when the attestation was last processed. As a result, the contract can't determine if the attestation has expired since the last processing, and it won't be aware of any pruning that occurred in the QGB module.

The Tendermint security model establishes a trusting period to ensure that validators with over 2/3 of the voting power, who signed the block, are behaving correctly during this period. In simple terms, once the trusting period is over, we must assume that validators could act arbitrarily.

• The Solidity contract doesn't check this trusting period, and it doesn't record the last time the checkpoint was updated. Consequently, the contract can't confirm if the trusting period has passed since the last update. Even though the QGB design updates the validator set as soon as a validator starts unbonding, issues might arise if the attestation containing this update isn't accepted on the QGB Smart Contract.

Problem Scenarios

If no attestation processing (including valset updates and data commitments) occurs for a period longer tshan the attestation expiry time, it can be attributed to the following reasons:

• Validators may not be signing
• It's possible that a relayer is unable to transfer the ValSetUpdate on Ethereum. This could be due to factors such as high transaction fees, lost connections, and so on.
• There might not be active or honest relayers or orchestrators/validators available to reach the necessary voting power threshold.

As a result, the current checkpoint in the Solidity contract may become disconnected from the current status of bonded and unbonding validators on the Cosmos side.
It's essential to understand that the Solidity smart contract is:

• under the complete control of the validators within the checkpoint and
• expecting the nonce, next to be processed and is unaware of the pruning happened on the QGB module, which deleted nonces.

Recommendation

Address the issue with implementing a check for the age of the current checkpoint and time passed from the latest attestation processed.
Alternatively, the design choice should be made explicit in the documentation.