AztecProtocol
Introduce clock tolerance for slot validation of attestations and block proposals similar to MAXIMUM_GOSSIP_CLOCK_DISPARITY
Current implementation of block proposal and attestation validation penalizes peers based on slot numbers (current or next slot are allowed).
async validate(message: BlockAttestation): Promise<PeerErrorSeverity | undefined> {
const slotNumberBigInt = message.payload.header.slotNumber.toBigInt();
try {
const { currentProposer, nextProposer, currentSlot, nextSlot } =
await this.epochCache.getProposerAttesterAddressInCurrentOrNextSlot();
if (slotNumberBigInt !== currentSlot && slotNumberBigInt !== nextSlot) {
this.logger.warn(
`Attestation slot ${slotNumberBigInt} is not current (${currentSlot}) or next (${nextSlot}) slot`,
);
return PeerErrorSeverity.HighToleranceError;
}
This validation can be abused by the attacker when a valid message is sent at the end of the slot so direct peers validate the message correctly, then broadcast the message but subsequent nodes treat it as invalid and penalize those peers.
Ethereum consensus layer deals with this by introducing MAXIMUM_GOSSIP_CLOCK_DISPARITY clock tolerance of 500ms.
MAXIMUM_GOSSIP_CLOCK_DISPARITY must be used for validation of blocks and attestations before forwarding them on the network:
MAXIMUM_GOSSIP_CLOCK_DISPARITY provides some leeway in validating slot ranges to prevent the gossip network from becoming overly brittle with respect to clock disparity. For minimum and maximum allowable slot broadcast times, MAXIMUM_GOSSIP_CLOCK_DISPARITY MUST be subtracted and added respectively, marginally extending the valid range. Although messages can at times be eagerly gossiped to the network, the node's fork choice prevents integration of these messages into the actual consensus until the actual local start of the designated slot.
Similar clock tolerance solution should be introduced to ignore messages that were valid but has just became invalid due to the timing issues and network latency.
Additional analysis should be performed to fully understand the scope of changes and all the scenarios where MAXIMUM_GOSSIP_CLOCK_DISPARITY is used in Ethereum consensus layer and if this applies to Aztec nodes.
