Thanks @michaelsproul for reaching us for a comment. Grandine uses parallelization, and it’s hard to prove parallel algorithms formally, so this is not something we are actively researching. But it’s really great to see this is moving forward.
Generally speaking, Grandine has similar optimizations. Some optimizations didn’t yield significant results (i.e. “Exit Cache”) so we removed it. Maybe it makes sense to roughly measure what is the impact of each optimization so that client teams can decide whether it’s worth implementing it.
A few random thoughts from the team:
Can the exit cache be simplified?
Does ExitCache really need to store counts for past epochs?
Wouldn’t storing just the latest values of exit_queue_epoch and exit_queue_churn be enough?
class ExitCache:
exit_queue_epoch: Epoch
exit_queue_churn: uint64
Are we missing something?
Effective balances fit in a single byte
Effective balances are multiples of EFFECTIVE_BALANCE_INCREMENT with a maximum of MAX_EFFECTIVE_BALANCE.
The values of the two variables in mainnet and minimal presets are such that an effective balance can only have 33 distinct values.
Storing them as bytes would save memory and may speed up some operations, but the required conversions would add overhead.
We haven’t implemented this in Grandine yet, so we’re not sure if it’s worth it.
Will increase_balance pose any problems?
Unlike decrease_balance, increase_balance does not saturate.
The letter of consensus-specs is that an overflow should make the entire state transition invalid.
This is not a big concern in practice[1], but we imagine it may get in the way of formal verification.
If the only goal is to prove equivalence with consensus-specs, this might not be a problem.
Invalid test data may prevent optimizations
This is more of a grievance than feedback, but it may be relevant.
Some test cases in consensus-spec-tests contain data that is invalid or cannot be reached through state transitions[2].
For example, the random test cases[3] for Phase 0 contain pre-states with impossible inclusion delays, necessitating a check[4] that should not be needed in a real network.
Test cases like these restrict the optimizations possible in a compliant implementation.
[1]: There is not enough ETH in the mainnet, though a malicious testnet operator could exploit this by submitting a very large deposit.
[2]: Like a Garden of Eden.
[3]: Only randomized_0 as of v1.4.0-beta.2. randomized_5 also appears to be invalid in some versions, including v1.3.0.
[4]: Albeit one with a negligible cost.