Sanity checks on inferred data
Closed this issue · 4 comments
There should be sanity checks on inferred data that forbid submitting a tx unless --force flag is set. More or less along the lines of "rewards can't exceed 20%/365 per day, slashings beyond reported only with --force flag, do not report duplicates" etc.
Some notes:
Now the Oracle contract doesn't check the relative numbers like reward - it's in backlog and hasn't been implemented. When it will be there, the daemon will discover that TX is insane via TX calling (it's there in both pyrmont and daemon_v2).
The ability to execute the TX is already checked just before sending on the net by replaying it in the VM (see
Line 195 in 86d343d
The on-chain reverts are possible and depend on timing (more aggressive WAIT - more probable tx races).
These effects can be minified by:
- improving the algorithm to avoid synchronisation around the global event (now daemons tend to synchronize around the moment of frame switch in ETH1). Working on it. If we switch to
look backbehavior instead ofwaitingthe new frame, this won't be the issue. - some sort of collision detection with rollbacks (watch for the pool, and if there is already the number of TXes that exceed the quorum, the exceeded ones should be self-identified and cancelled by initiators. Need to specify some kind of pseudorandom tiebreaker, stepping and feedback similarly to Physical collision detection on the wire protocols. This also will need to have the node with web3.pool exposed (this won't work via infura and other public endpoints).
We don't have the capacity to implement it in the contracts so we're doing it in the daemon. The issue is to prevent massively wrong (due to a bug) data to propagate on chain.
Discussed on the calls - it's (at some degree) possible within the contracts and relies on the ability to virtually play transaction in EVM before serializing on the net. This costs no gas and we already use this approach. Related issues:
Actual logic and math:
lido-dao#176
lido-dao#175
lido-dao#39
Cosmetics (hide EVM traceback, show human-readable log):
#44
PS: More intelligent checks are possible with a stateful oracle (for example, it's able to keep the individual balances and states of the validators, compare and assert changes on each run). This needs switching to ORM and more complex infra configs with Docker volumes. Moved to the separate issue #51