Refactor to allow for single sponsorWallet updates

[acenolaza]

What does this change?

It basically applies suggestion made here to allow sending txs using a single sponsor wallet. This is meant to be used by a deployment used a fallback that should send txs whenever main airseeker deployments are down their sponsorWallets have run out of funds for some reason. This fallback deployment also makes our lives easier by not having to top-up the sponsorWallet of each dAPI.

1. Adds a new wallet derivation scheme type called fallback
2. It also adds a new property to walletDerivationScheme config object called sponsorAddress. This property must be set to a valid address when walletDerivationScheme.type is fallback
3. pendingTransactionsInfo objects are now keyed by dataFeedId instead of sponsorWalletAddress
4. The getRecommendedGasPrice() nows receives an array of dataFeedIds instead of a single sponsorWalletAddress as argument and it only uses the oldest pendingTransactionsInfo (when more than 1 dataFeedId is passed)
5. There is a new submitBatchTransaction() function that bundles all the calldatas required to update all data feeds in the batch and sends a single tryMulticall() tx.

[bbenligiray]

It also adds a new property to walletDerivationScheme config object called sponsorWallet.

Looks like you mean sponsorAddress.

I dislike "fallback", something like "fixed" would be semantically less restrictive

pendingTransactionsInfo objects are now keyed by dataFeedId instead of sponsorWalletAddress

I thought we decided not to touch this on a recent call. Doesn't self-funded scheme update the same data feed (with ID) using multiple sponsor wallets belonging to different update parameters?

[acenolaza]

Looks like you mean sponsorAddress.

Good catch. Updated comment

I dislike "fallback", something like "fixed" would be semantically less restrictive

👍🏻

I thought we decided not to touch this on a recent call.

That is correct but Emanuel made a good suggestion where by doing this change, retries get mostly fixed for single wallet

Doesn't self-funded scheme update the same data feed (with ID) using multiple sponsor wallets belonging to different update parameters?

🤔 that is a good question and it seems we could be scaling the gas price for wallets that might not need it when self-funded is set. @Siegrift any thoughts on this? Maybe we can use both as keys 🤔

pendingTransactionsInfo: Record<
    ChainId,
    Record<string /* Provider name */, Record<Address /* Sponsor wallet */, Record<Hex /* Data Feed ID */, PendingTransactionInfo | null>>>
  >;

[acenolaza]

Maybe we can use both as keys 🤔

Implemented that here I'll wait for comments 🙏🏻

[Siegrift]

Doesn't self-funded scheme update the same data feed (with ID) using multiple sponsor wallets belonging to different update parameters?

🤔 that is a good question and it seems we could be scaling the gas price for wallets that might not need it when self-funded is set. @Siegrift any thoughts on this? Maybe we can use both as keys 🤔

Currently, Airseeker can update the same data feed using different wallets for self-funded (as @bbenligiray suggests in the question), but it can also happen when there are 2 active data feed using the same data feed ID (e.g. one identified by ID, one by dapiName). Airseeker now treats these separate and scales them independently. There is no case, where a single wallet updates multiple data feeds, so key-ing by both data feed ID and sponsor address solves the problem for "fixed" wallet derivation.

Another question is whether it doesn't make sense for this to only key this by data feed ID. In both managed/self-funded there we will be scaling unnecessarily (in the self-funded it depends on how often the deviation is triggered for multiple deviating feeds - but that seems probably enough). So I think it doesn't and we should do what you suggest.

I dislike "fallback", something like "fixed" would be semantically less restrictive

fwiw: I don't have a strong opinion about this.

[Siegrift]

It looks like this module copy-pastes a lot of existing functionality. Also, some changes are unnecessary and can be reverted.

[Siegrift]

FYI: I've edited the spec about the wallet derivation types here

[Siegrift]

Can you rebase please? I'll review then.

[Siegrift]

👍 Implementation looks good to me, but wait for @bdrhn9 's approve as well as this is a quite a significant change.

I think we already talked about this internally, but this should be tested on testnets before we attempt to roll it out for mainnets.

[bdrhn9]

Changes looks clean and good to me 💪🏼

[acenolaza]

Thank you both for all the feedback! 🚀

[acenolaza]

Thank you both for all the feedback! 🚀

Should I just merge now? How should we test these changes? Do you guys deploy to a testnet to verify everything is still working as expected?

[bdrhn9]

Thank you both for all the feedback! 🚀

Should I just merge now? How should we test these changes? Do you guys deploy to a testnet to verify everything is still working as expected?

I think changes looks good and mergeable. I will test these changes by deploying on one testnet. Maybe I'll remove actual deployment on that specific testnet to see whether our fallback airseeker gain control over.