feat: Add relayer repayment address

[chrismaree]

This PR changes the interface of two existing EVM functions: fillV3Relay & fillV3RelayWithUpdatedDeposit. They are extended to now contain repaymentAddress as the address the relayer wants to get repaid on on chain repaymentChainId.

one open question: do we want to support the old fillV3Relay interface, without this new prop, that just internally maps this address to msg.sender on EVM? this will enable current relayers to continue to work without requiring them to upgrade. main reason against having this backwards compatibility is we are adding breaking changes in other places (eg here: #650) that will also force relayes to upgrade so it could be argued that we should simple upgrade all the things at once without backwards compatibility in any location.

[pxrl]

This change looks clean to me; I don't have any comments to the changes. Will leave opportunity for others to comment before approving.

one open question: do we want to support the old fillV3Relay interface, without this new prop, that just internally maps this address to msg.sender on EVM? this will enable current relayers to continue to work without requiring them to upgrade. main reason against having this backwards compatibility is we are adding breaking changes in other places (eg here: #650) that will also force relayes to upgrade so it could be argued that we should simple upgrade all the things at once without backwards compatibility in any location.

I think relayers will just deal with this but it's a headache for other integrators who are running infra against Across. Aggregators are an example - Socket and Li.Fi both have their own explorer implementations and they have specific knowledge about Across events. Wallet integrations is probably another stakeholder - Rabby can for instance decode Across transactions, so it'll probably impose some subtle breakage for them.

It's unfortunate they we'll be breaking some integrations and will be imposing re-work, though I should note it's not the first time that this will be happening because we already have an ABI break for events in the current audit (RE deterministic deposit IDs). I don't think there's necessarily anything to do differently here - we should just be extra persuasive in encouraging integrators to migrate to our new app SDK, which will permit us to handle the breakage internally, such that others can make the transition by upgrading their package.

[chrismaree]

^

[mrice32]

Only one comment

[mrice32]

Should we change this to repaymentAddress for consistency?

[chrismaree]

we could BUT it's called relayer in the event and we don't really want to change the name there, do we?

[mrice32]

This change looks clean to me; I don't have any comments to the changes. Will leave opportunity for others to comment before approving.

one open question: do we want to support the old fillV3Relay interface, without this new prop, that just internally maps this address to msg.sender on EVM? this will enable current relayers to continue to work without requiring them to upgrade. main reason against having this backwards compatibility is we are adding breaking changes in other places (eg here: #650) that will also force relayes to upgrade so it could be argued that we should simple upgrade all the things at once without backwards compatibility in any location.

I think relayers will just deal with this but it's a headache for other integrators who are running infra against Across. Aggregators are an example - Socket and Li.Fi both have their own explorer implementations and they have specific knowledge about Across events. Wallet integrations is probably another stakeholder - Rabby can for instance decode Across transactions, so it'll probably impose some subtle breakage for them.

It's unfortunate they we'll be breaking some integrations and will be imposing re-work, though I should note it's not the first time that this will be happening because we already have an ABI break for events in the current audit (RE deterministic deposit IDs). I don't think there's necessarily anything to do differently here - we should just be extra persuasive in encouraging integrators to migrate to our new app SDK, which will permit us to handle the breakage internally, such that others can make the transition by upgrading their package.

I agree. I think we should batch any updates to interfaces/abis.

[mrice32]

One open question is whether we should keep a backwards compatible fill interface.

This ties into how we're planning to orchestrate the migration. My straw man:

• We keep RelayData hash abi compatible (I think we can do this), so we know that old deposits and new deposits will collide if they have the same info.
• Both fill functions can still work with both the old deposit event and new deposit event.
• We keep both fill functions even after we do the deposit event upgrade, so relayers must start watching the new event, but can migrate the fill function they call at their own leisure. Old fill function is considered deprecated.
• We remove the old fill function in a later upgrade.

Thoughts?

[chrismaree]

One open question is whether we should keep a backwards compatible fill interface.

This ties into how we're planning to orchestrate the migration. My straw man:

• We keep RelayData hash abi compatible (I think we can do this), so we know that old deposits and new deposits will collide if they have the same info.
• Both fill functions can still work with both the old deposit event and new deposit event.
• We keep both fill functions even after we do the deposit event upgrade, so relayers must start watching the new event, but can migrate the fill function they call at their own leisure. Old fill function is considered deprecated.
• We remove the old fill function in a later upgrade.

Thoughts?

I like this and it leans into why I wanted to keep the event structure the same and only change the relayer field :)

[md0x]

Question: Why are we moving from the relayer public key to address_zero here?

[Reinis-FRP]

I think we had it wrong and EVM implementation passes empty address as well

[md0x]

Looks good to me! Just had a question

[Reinis-FRP]

looking good

[chrismaree]

^

[pxrl]

Very odd 🤔