feat: handle offline validators on the consumer chain side and punish them on provider

[tbruyelle]

we need to setup the following punishement for offline validators:

• no distributed fees
  • this can be based on non-signed blocks, but this requires the provider to have access to all consumer blocks
  • an other approach can be to exclude offline validator for a predefined period (i.e. one day)
• slash w/o jail for a percentage based on the fees. The exact computation needs to be defined.

"offline" needs to be defined as well, like what is the SignedBlockWindow and what is the MinSignedPerWindow. These parameters doesnt have to be the same as the x/slashing module.

Based on this "offline" definition, we also need to define a way for the consumer chain to send the information to the provider. This can be something similar to the slashing module, the consumer module tracks sdkctx.VoteInfos() for each blocks and aggregate the data (see slashingkeeper.HandleValidatorSignatures()). Then at some epoch, the info is propagated to the provider chain using an IBC message.

Based on the received information, the provider module punishes the offline validators. Maybe we can link the fee distribution to this message's reception, for 2 reasons:

• fees are no longer distributed for each blocks, which can be a performance bottleneck (see Consider delaying fee distribution #35 )
• this creates an incentivization for the validators of the consumer chain to send this message, because if they dont in order to avoid punishement, they also dont get paid.

I understand theres is a lot of things to figure out here, let's try to iterate in this issue for a more detailed design.

[tbruyelle]

question list:

• how do we compute the slash percentage from the ICS fees ?
• fee distribution exclusion: for a period (like a day) or only for the non-signed blocks?
• consumer offline validator report: can we aggregate the data to avoid sending all the signed blocks (but then how the provider verify the data ?), or should we send all the signed blocks (lots of info) and the provider does the aggregation.
• should we trigger the fee distribution to that offline validator report reception, for the following reasons ?
  • fees are no longer distributed for each blocks, which can be a performance bottleneck (see Consider delaying fee distribution #35 )
  • this creates an incentivization for the validators of the consumer chain to send this message, because if they dont in order to avoid punishement, they also dont get paid.

[giunatale]

Addressing the questions:

Assuming we have a MissedBlocksBitArray of configurable size SignedBlocksWindow and a defined MinSignedPerWindow that allows us to retrieve maxMissed as SignedBlocksWindow - (MinSignedPerWindow * SignedBlocksWindow) (as x/slashing does).
Not sure having/relying on x/slashing per se makes sense, but still we need these. Probably can't really reuse x/slashing because preferably this is not a sliding window, but it get's reset every distribution epoch.

SignedBlocksWindow and MinSignedPerWindow would be provider-configured params which are inherited (and updated) on the consumer via IBC. Say SignedBlocksWindow is a day worth of blocks and MinSignedPerWindow is 50%. Assume SignedBlocksWindow is in sync with the epoch identifier of the ICS fees distribution (so that also happens once a day). Again, MissedBlocksBitArray should be reset at each distribution epoch (i.e. every "day" you get a fresh MissedBlocksBitArray).

1. how do we compute the slash percentage from the ICS fees ?

If a validator is flagged from exclusion from the ICS fees for a round because it didn't sign enough blocks, compute slashing as: amount of photon it would have received for that round if it was included (call it P) * photon to atone conversion rate (call it C) * percentage of missed block during that period i.e. MissedBlocksCounter / SignedBlocksWindow (call it M): P * C * M.

2. fee distribution exclusion: for a period (like a day) or only for the non-signed blocks?

exclude from the round of distribution entirely. Simpler, and logically still sound. Validator didn't do its job during this period, even though it signed some of the blocks (but not enough to qualify for the reward). Distribution should happen slightly later than end-of-period though so that distribution logic can still collect potential evidence packets.

3. consumer offline validator report: can we aggregate the data to avoid sending all the signed blocks (but then how the provider verify the data), or should we send all the signed blocks (lots of info)

Just send the MissedBlocksBitArray once maxMissed is exceeded. Consumer-chain initiated "evidence packet".

4. should we trigger the fee distribution to that offline validator report reception, for the reason invoked ?

Not sure I understand what you mean here.

---

feel free to push back on anything.

[tbruyelle]

Sounds good to me for 1 and 2.

For 3 that means the provider chain has to trust the consumer chain, because as far as I can tell anyone can forge a MissedBlocksBitArray. Dont you think it can be dangerous?

4 is about moving the current per-block fee distribution to, not an epoch-based, but to a consumer chain block report reception-based. But this doesnt work with MissedBlocksBitArray since this one is sent only if MaxMissed is exceeded as you stated it. This works only if consumer block report are received regularly by the provider chain, even if all validators has signed.

This is probably less efficient than the MissedBlocksBitArray, so essentially the choice depends on weither or not we need the provider to verify the block report (point outlined for 3).

[giunatale]

Dont you think it can be dangerous?

potentially indeed the code on the consumer chain could be malicious and produce faulty/forged MissedBlocksBitArray.

Sending all block data is simply unfeasible, we need to rely on aggregated data. Still thinking, but we need to find anyway an alternative to sending block data. It's too much to handle

[giunatale]

cont'd:

We might want to consider two possible options:

---

Option A — Optimistic challenges

The bitmap doesn't need to be honest, it just needs to survive a challenge window. Forging a signature is infeasible; producing one isn't proof of liveness on its own (votes don't bind to creation time), but a Merkle inclusion proof of the validator's signature in some LastCommit inside the disputed window does — anchored via the IBC light client's already-verified headers.

Flow:

1. Consumer submits aggregated bitmap, slashing is queued behind a challenge window.
2. Anyone can challenge with (header, LastCommit, inclusion proof, skip-chain to a trusted IBC header).
3. Provider verifies via existing IBC client logic + one signature check. Valid challenge cancels the slash. Valid challenge also results in the consumer being halted and scheduled for deletion
4. No challenge results in the slash being executed.

Option B — Provider-anchored heartbeats

Skips the consumer-chain trust assumption entirely. Each validator periodically submits a heartbeat to the provider, signed over a recent provider block hash. Because they can't know that hash ahead of time, the heartbeat proves liveness at that provider height. Missed heartbeats over a window causes slash, independent of any bitmap.

This solution is heavier than (A) in terms of cost. Also not entirely clear how it would work in practice, but worth throwing in the mix. It's also dependent on how frequently these heartbeats are required, of course more frequent means more costly.

Worth noting this solution however would be more feasible for example with gno.land

---

Need further expansion/thinking, but worth considering as starting point for discussion.

[tbruyelle]

I like Option A, that's the more realistic one.

So in a scenario where the fee distribution is bitmap-arrival triggered, here is the workflow:

Window N ends on consumer:

• consumer sends bitmap via IBC
• provider receives bitmap
• provider distributes fees for window N (excluding flagged validators)
• provider slashes flagged validators (after challenge window)
• bitmap reset on consumer for window N+1

Note1: a valid challenge doesnt avoid exclusion from fee distribution. This is a simplification, because otherwise we need to escrow the fees before distribution. Considering that the outcome of a valid challenge is the consumer chain deletion, I think this is OK.

Note2: while the consumer deletion in case of valid challenge is legit, it might be a bit too catastrophic in case the consumer chain has a bug that generates incorrect bitmaps. Maybe a new PAUSE phase is better (similar to STOPPED), with a gov proposal to re-activate it. This would also reduce the incentive for consumer teams to suppress challenges, for example by bribing validators not to challenge or by attacking the submission process.

[giunatale]

Just to clarify, and relaying the discussion we had over the call:
only bitmaps where infractions (more than maxMissed) are detected are relayed to the producer.

Regarding note 1.
what I personally had in mind:

• at epoch close, there's a sufficient delay for processing/distribution on the producer to wait for potential evidence bitmaps
• if no evidence is received (including during the buffer period), distribution happen normally
• if evidence is received, distribution happens normally for everyone that wasn't flagged for downtime, fees for the validator(s) subject to the challenge period do go in escrow. A challenge timer starts.
• If no challenge within the window, fees are distributed to the other validators equally, the amount is used to compute the slash, slash is executed. In particular, ICS fees are sent to a separate "accumulator" so that if more than one validator were being challenged, this "accumulator" can collect all claimed fees and hold a record of the list of validators to distribute to (that can have validators added in case of a successful challenge). At the end of all challenge periods (for multiple infractions in the same epoch) the "accumulator" performs the distribution.
• if challenge arrives and is valid, escrowed fees are released, consumer is scheduled for punishment

Regarding note 2, it makes a lot of sense. Basically chain is STOPPED and a proposal is sent to governance to evaluate wether to restart the chain. Sounds good to me.