feat(compliance): add spec compliance for EREP-10 and STO-040/041

[0xfourzerofour]

Closes #452 #448 #480

Proposed Changes

• add spec compliance by creating structure to keep track of paymaster balances
• add compliance for STO-040/041
• add compliance for EREP-10
• Change error codes to return opcode error instead of unstaked error in compliance with the 4337 team

[codecov]

Codecov Report

Attention: 247 lines in your changes are missing coverage. Please review.

Comparison is base (4f2ffe8) 55.17% compared to head (87f77e2) 57.06%.
Report is 2 commits behind head on main.

Additional details and impacted files

Files	Coverage Δ
crates/pool/src/mempool/entity_tracker.rs	100.00% <100.00%> (ø)
crates/pool/src/mempool/error.rs	76.19% <ø> (ø)
crates/pool/src/mempool/mod.rs	96.42% <100.00%> (+0.04%)	⬆️
crates/provider/src/traits/paymaster_helper.rs	100.00% <100.00%> (ø)
crates/sim/src/gas/gas.rs	88.97% <ø> (-0.23%)	⬇️
crates/sim/src/precheck.rs	75.60% <100.00%> (ø)
crates/sim/src/simulation/mempool.rs	96.20% <100.00%> (+0.04%)	⬆️
crates/sim/src/simulation/tracer.rs	33.80% <100.00%> (+2.92%)	⬆️
crates/types/src/user_operation.rs	100.00% <100.00%> (ø)
crates/pool/src/chain.rs	92.04% <99.49%> (+1.64%)	⬆️
... and 12 more

... and 9 files with indirect coverage changes

Flag	Coverage Δ
unit-tests	57.06% <81.75%> (+1.88%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
rundler binary	0.00% <ø> (ø)
builder	50.09% <33.33%> (ø)
dev	0.00% <ø> (ø)
pool	63.79% <86.17%> (+5.05%)	⬆️
provider	0.91% <14.28%> (-0.05%)	⬇️
rpc	37.42% <0.00%> (-1.08%)	⬇️
sim	83.48% <50.81%> (+0.28%)	⬆️
tasks	∅ <ø> (∅)
types	90.25% <53.33%> (-1.26%)	⬇️
utils	14.96% <0.00%> (-0.17%)	⬇️

[dancoombs]

There is a lot of complexity and a large amount of edge cases here. Would be worth writing tests on the uo_pool object with different combinations of deposits, reorgs of both UOs and deposits, dropped UOs etc.

In general I'm concerned that a bug here could lead us to unfairly block a paymaster and require a restart of Rundler to unstick. We probably need more visibility into these balances as well as some sort of kill switch. Metrics aren't ideal since this is high dimensional. Maybe we consider adding an admin API.

[0xfourzerofour]

There is a lot of complexity and a large amount of edge cases here. Would be worth writing tests on the uo_pool object with different combinations of deposits, reorgs of both UOs and deposits, dropped UOs etc.

In general I'm concerned that a bug here could lead us to unfairly block a paymaster and require a restart of Rundler to unstick. We probably need more visibility into these balances as well as some sort of kill switch. Metrics aren't ideal since this is high dimensional. Maybe we consider adding an admin API.

Yes, there is a lot of random complexity that is hard to make sure everything is captured. I agree we should have an admin endpoint to reset the balance/ call from the onchain state

[dancoombs]

Lets go! Thanks for working through this, so many edge cases to discover and work out.

🚀