feat: solana backoff deposit witnessing

[kylezs]

Pull Request

Closes: PRO-1984

Checklist

Please conduct a thorough self-review before opening the PR.

• I am confident that the code works.
• I have written sufficient tests.
• I have written and tested required migrations.
• I have updated documentation where appropriate.

Summary

This will drastically reduce the number of RPC requests related to deposit witnessing. We can probably do something similar for egress witnessing too.

[codecov]

Codecov Report

Attention: Patch coverage is 42.85714% with 80 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...ntime/src/migrations/backoff_settings_migration.rs	0%	57 Missing ⚠️
...lectoral_systems/blockchain/delta_based_ingress.rs	74%	4 Missing and 5 partials ⚠️
engine/src/elections/voter_api.rs	0%	3 Missing ⚠️
engine/src/witness/sol.rs	0%	3 Missing ⚠️
...ts/cf-elections/src/electoral_systems/composite.rs	0%	2 Missing ⚠️
...chain/pallets/cf-elections/src/electoral_system.rs	0%	1 Missing ⚠️
...allets/cf-elections/src/electoral_system_runner.rs	0%	1 Missing ⚠️
...-elections/src/electoral_systems/egress_success.rs	0%	1 Missing ⚠️
...ets/cf-elections/src/electoral_systems/liveness.rs	0%	1 Missing ⚠️
...lections/src/electoral_systems/monotonic_change.rs	0%	1 Missing ⚠️
... and 1 more

📢 Thoughts on this report? Let us know!

[marcellorigotti]

LGTM!

[MxmUrw]

Looking good! One question for my understanding: are we sure that the engines are voting for each statechain block?

[MxmUrw]

This would probably be more readable if we apply the negation to the clauses:
(current <= opened + backoff) || (current % freq == zero)

[kylezs]

Looking good! One question for my understanding: are we sure that the engines are voting for each statechain block?

Good question. The answer is no. You're asking because when we backoff, we have to have got the elections at that particular block in order for the mod = 0 condition to be true? ... I thought about it, and figured given this is a kinda of backup case anyway, as in, we assume we deposit in the first hour anyway, then a potential added 10 minute delay isn't that bad. Plus, it's quite unlikely we hit this case given we query every 6 seconds anyway.

[marcellorigotti]

Looking good! One question for my understanding: are we sure that the engines are voting for each statechain block?

Good question. The answer is no. You're asking because when we backoff, we have to have got the elections at that particular block in order for the mod = 0 condition to be true?

Why would we miss an election at a particular block? isn't the engine processing all the state-chain blocks? 🤔

[kylezs]

Why would we miss an election at a particular block? isn't the engine processing all the state-chain blocks? 🤔

You're right actually. Was thinking about submission. But for processing of the data we use the unfinalised stream, so even better :)

engine/src/elections.rs

if let Some(block_info) = unfinalized_block_stream.next() => {

[MxmUrw]

You're right actually. Was thinking about submission. But for processing of the data we use the unfinalised stream, so even better :)

I'm not sure whether this changes things, if we start processing the data for some block with height % freq = 0, but aren't fast enough to submit it, then the next chance will be in 10 minutes anyways, right?

[...] then a potential added 10 minute delay isn't that bad.

I agree with this though.

[dandanlen]

I feel like there's something a little leaky about the abstraction here... maybe there's a better way to tackle this?

(Not saying I know what it is, just that something doesn't feel quite right here)

Basically, it feels like this is neither encapsulated in the abstraction layer of electoral systems, nor fully hidden inside the implementation of the election. It sort of exists in both, but is not useful in either piece individually.