feat(relayer): Support ignoring FilledV3Relay events #1339
Conversation
Making room for follow-up changes to improve relayer performance.
Rather than duplicating the array of unfilled deposits, just check it as the first conditional in the subsequent loop. This allows the entire function to be subsequently factored away, which will occur in a follow-up commit.
Factoring out this functionality permits it to be executed in parallel per destination chain.
…layerRefactorEvaluate
…layerRefactorEvaluate
The relayer currently implements late-stage checking of the fill status on a per-deposit basis. This is fairly slow and inefficient, but does successfully protect against an avalanche of failed fill simulations that result from overlapping bot runs. This change implements batched querying of all deposits for each destination chain. This is significantly more efficient in terms of RPC consumption, and should allow for subsequent "already filled" filtering to occur much faster. It's also a key enabler for some subsequent efficiency improvements.
This commit makes the SpokePoolClient FilledV3Relay query optional, subject to the ACCEPT_INVALID_FILLS env var being defined true. This ensures that the behaviour is opt-in. This is enabled by the recent change to query the fill status of all outstanding deposits. Since there's no need to submit the LP fee onchain in Across v3, the risks of opting into this setting are significantly reduced, whilst the benefits are: - Reduced SpokePoolClient update times. - Reduced overheads in matchind deposits with fills.
pxrl
requested review from
mrice32,
nicholaspai and
james-a-morris
as code owners
Really good consideration - it would. It's a useful feature for third-parties to have so I think it's probably worth having, but I wonder if it should also be conditional on inventory management being disabled. I've marked it |
|
We can probably re review this again after changing how bundle refunds are computed in the InventoryManager. If we can fetch them from Arweave then this PR can be useful even with InventoryManager enabled |
There was a problem hiding this comment.
I think we can evaluate this after local testing now that we load most bundle data from arweave. However, there is still a case where we'd want to comute bundles from events when there is no bundle pending. This happens in the short window (~15 mins max) between last bundle execution and next bundle proposed.
This PR would cause the Inventory Manager to not count any bundle refunds in that time, which probably is not a big deal and worth the speed up if it is signficiant
I think this pr is now intractable if we're going to go with the bundle refund approximation approach in #1382 |
Yep, agreed. Time for it to be closed. |
This commit makes the SpokePoolClient FilledV3Relay query optional, subject to the ACCEPT_INVALID_FILLS env var being defined true. This ensures that the behaviour is opt-in.
This is enabled by the recent change to query the fill status of all outstanding deposits. Since there's no need to submit the LP fee onchain in Across v3, the risks of opting into this setting are significantly reduced, whilst the benefits are: