alloy
alloy copied to clipboard
alloy-rs
feat(alloy-provider): add abstraction for `NonceFiller` behavior
Motivation
Resolves #1073
Solution
I added trait NonceManager and two implementations: SimpleNonceManager and CachedNonceManager to allow the user to choose the behavior of nonces filling. In the recommended fillers, I also changed the implementation from CachedNonceManager to SimpleNonceManager to make the recommended fillers more resilient to chain reorganizations. The issue was described in more detail in https://github.com/alloy-rs/alloy/issues/1073#issuecomment-2251181724.
PR Checklist
- [ ] Added Tests
- [x] Added Documentation
- [x] Breaking changes
Good point on the re-org resistance. An alternative solution could be to have a function a user can call to refetch the nonce, overwriting the cache entry. Assuming they have a system that is re-org aware they can simply call this function. I would prefer that over having two distinct implementations.
@zerosnacks
An alternative solution could be to have a way of having a user be able to indicate that the nonce needs to be refetched.
Even if we indicate whether to fetch nonce from the rpc when sending the rpc request, it will still be inconvenient since you won't be able to fully customize the behavior as you wish.
Even if we indicate whether to fetch nonce from the rpc when sending the rpc request, it will still be inconvenient since you won't be able to fully customize the behavior as you wish.
Could you expand on that? What kind of behavior would you be customizing that is not covered by my proposed approach?
@zerosnacks this will help implement any behavior, but on the caller side you will need to pass a boolean value or use some wrapper, which seems inconvenient on the caller side. We will also need wrappers for providers, alloy::contract, etc.
Also consider that you can't just get a NonceFiller instance and indicate it to fetch rpc, since it might be wrapped with JoinFill. So you'll have to invent some mechanism to interact with the NonceFiller via interior mutability.
cc @onbjerg / @prestwich curious to hear your thoughts on this proposal / approach
It makes sense to have other types of nonce management strategies. You can already do this using a custom filler, but this simplifies implementing a new nonce strategy somewhat, so I think this is ok.
Noting that this is a breaking change, though
cc @mattsse
