Relayer: query swap/join/exit (V2)

[EndymionJkb]

Description

This is a full version of the Relayer: except it also exposes a queryMulticall that does queries instead of actual operations, using a second "stripped down" relayer deployment that only implements query Vault actions. It's an alternative to PR #2516, which is a "drop-in" relayer that would be called instead of the standard (full featured) one.

Tests check that calls to the queryMulticall give the same results as BalancerQueries, and do not require approvals.

Type of change

• Bug fix
• New feature
• Breaking change
• Dependency changes
• Code refactor / cleanup
• Documentation or wording changes
• Other

Checklist:

• The diff is legible and has no extraneous changes
• Complex code has been commented, including external interfaces
• Tests are included for all code paths
• The base branch is either master, or there's a description of how to merge

Issue Resolution

Closes #2209

[danielmkm]

I would lean towards this implementation over the one in #2516 if the bytecode limitations can be overcome. imo, it's easier to inform someone to call queryMulticall vs multicall on the same contract instead of calling two different contracts with the same function.

It could also be useful to change the name queryMulticall in someway that more clearly says that it can only be used for vault actions, ie: queryVaultActions, queryVaultActionsMulticall.

[danielmkm]

I think this will provide a huge quality of life improvement generally, but the VaultQueryActions here do not stack the same way they do with the peek functionality on the existing batch relayer. IE: If a chain of actions impact the same pool more than once, those changes are properly represented with the existing peek, but are not represented with this approach.

There is no way around this, but I would expect the limitation to be clarified somehow, whereas currently this would only be found after some serious debugging by an integrator

[danielmkm]

I like that you maximize code reuse by implementing VaultActions. 👍

[gmbronco]

--When calling multicall with vault authorisation signature, the relayer fails with 430 (low level failure). Not sure if that's intended? Should I add a test case?---

My bad, I was using a relayer library address at initialization.

[brunoguerios]

I've been using a locally deployed relayer from this branch and I identified an issue when querying for chained exits.
It seems to be ignoring the outputReference index provided.
Being more concrete with an example:
While exiting 3-POOL (0x79c58f70905f734641735bc61e45c19dd9ad60bc) on mainnet, which has the following tokens:

- 0x6b175474e89094c44da98b954eedeac495271d0f (DAI)
- 0x79c58f70905f734641735bc61e45c19dd9ad60bc (3-POOL-BPT)
- 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 (USDC)
- 0xdac17f958d2ee523a2206206994597c13d831ec7 (USDT)

for the query call, if I set the output references as:

outputReferences [
  {
    index: 0,
    key: 84158459389524002386711626555386694745894712975979482213248346579970065170542
  },
  {
    index: 2,
    key: 84158459389524002386711626555386694745894712975979482213248346579970065170544
  },
  {
    index: 3,
    key: 84158459389524002386711626555386694745894712975979482213248346579970065170545
  }
]

and peek their values, it actually returns values for token indexes 0, 1 and 2 instead of 0, 2 and 3.
This is just one example, but I'm able to reproduce the same behavior on a few different transactions.

[jubeira]

Great job! I only have a few nits as comments; otherwise LGTM.

Can we please add a test for the fix in a958b17?

@brunoguerios I understand you've tested the fix already. Do you have any other findings to share with us, or do you think this is good to go?

[jubeira]

LGTM, thanks @EndymionJkb !
The error in CI is unrelated; probably an issue with Foundry's nightly release.

Let's proceed with the PR, and get one final thumbs up from @brunoguerios before deploying.

[brunoguerios]

My tests are all passing with a relayer deployed from the latest commit, so on my end it's ok 👍