feat: Add relayer repayment address #653

chrismaree · 2024-10-11T13:20:35Z

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.

Signed-off-by: chrismaree <[email protected]>

pxrl · 2024-10-15T12:49:05Z

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 · 2024-10-15T15:44:07Z

contracts/SpokePool.sol

@@ -1311,7 +1311,7 @@ abstract contract SpokePool is
    // exclusiveRelayer if passed exclusivityDeadline or if slow fill.
    function _fillRelayV3(


mrice32

Only one comment

mrice32 · 2024-10-16T13:42:45Z

contracts/SpokePool.sol

@@ -1311,7 +1311,7 @@ abstract contract SpokePool is
    // exclusiveRelayer if passed exclusivityDeadline or if slow fill.
    function _fillRelayV3(
        V3RelayExecutionParams memory relayExecution,
-        address relayer,
+        bytes32 relayer,


Should we change this to repaymentAddress for consistency?

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

mrice32 · 2024-10-16T13:45:13Z

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 · 2024-10-17T07:52:44Z

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 · 2024-10-17T14:54:41Z

programs/svm-spoke/src/instructions/slow_fill.rs

@@ -256,7 +256,7 @@ pub fn execute_v3_slow_relay_leaf(
        fill_deadline: relay_data.fill_deadline,
        exclusivity_deadline: relay_data.exclusivity_deadline,
        exclusive_relayer: relay_data.exclusive_relayer,
-        relayer: *ctx.accounts.signer.key,
+        relayer: Pubkey::default(), // There is no repayment address for slow


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

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 · 2024-10-21T10:54:19Z

hardhat.config.ts

@@ -52,7 +52,7 @@ const DEFAULT_CONTRACT_COMPILER_SETTINGS = {
    optimizer: { enabled: true, runs: 1000000 },
    viaIR: true,
    // Only strip revert strings if not testing or in ci.
-    debug: { revertStrings: isTest ? "default" : "strip" },
+    debug: { revertStrings: isTest ? "debug" : "strip" },


Very odd 🤔

Signed-off-by: chrismaree <[email protected]>

chrismaree added 4 commits October 11, 2024 15:19

WIP

a2e4842

Signed-off-by: chrismaree <[email protected]>

WIP

41bd6c0

Signed-off-by: chrismaree <[email protected]>

WIP

fee79f3

Signed-off-by: chrismaree <[email protected]>

WIP

7b9cd50

Signed-off-by: chrismaree <[email protected]>

chrismaree changed the title ~~Add relayer repayment address~~ feat: Add relayer repayment address Oct 14, 2024

WIP

fa1d38f

Signed-off-by: chrismaree <[email protected]>

chrismaree marked this pull request as ready for review October 14, 2024 12:16

chrismaree requested review from md0x and Reinis-FRP October 14, 2024 12:25

nicholaspai added the do not merge do not merge label Oct 15, 2024

chrismaree commented Oct 15, 2024

View reviewed changes

Merge branch 'master' into chrismaree/add-repayment-address

e3b320c

chrismaree changed the base branch from master to svm-dev October 16, 2024 12:39

mrice32 reviewed Oct 16, 2024

View reviewed changes

md0x reviewed Oct 17, 2024

View reviewed changes

md0x approved these changes Oct 17, 2024

View reviewed changes

Reinis-FRP approved these changes Oct 18, 2024

View reviewed changes

chrismaree commented Oct 21, 2024

View reviewed changes

WIP

7f31b38

Signed-off-by: chrismaree <[email protected]>

chrismaree merged commit aa36eb6 into svm-dev Oct 22, 2024
9 checks passed

chrismaree deleted the chrismaree/add-repayment-address branch October 22, 2024 10:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: Add relayer repayment address #653

feat: Add relayer repayment address #653

chrismaree commented Oct 11, 2024 •

edited

Loading

pxrl commented Oct 15, 2024

chrismaree Oct 15, 2024

mrice32 left a comment

mrice32 Oct 16, 2024

chrismaree Oct 17, 2024

mrice32 commented Oct 16, 2024

mrice32 left a comment

chrismaree commented Oct 17, 2024

md0x Oct 17, 2024

Reinis-FRP Oct 18, 2024

md0x left a comment

Reinis-FRP left a comment

chrismaree Oct 21, 2024

pxrl Oct 22, 2024

		@@ -1311,7 +1311,7 @@ abstract contract SpokePool is
		// exclusiveRelayer if passed exclusivityDeadline or if slow fill.
		function _fillRelayV3(

feat: Add relayer repayment address #653

feat: Add relayer repayment address #653

Conversation

chrismaree commented Oct 11, 2024 • edited Loading

pxrl commented Oct 15, 2024

chrismaree Oct 15, 2024

Choose a reason for hiding this comment

mrice32 left a comment

Choose a reason for hiding this comment

mrice32 Oct 16, 2024

Choose a reason for hiding this comment

chrismaree Oct 17, 2024

Choose a reason for hiding this comment

mrice32 commented Oct 16, 2024

mrice32 left a comment

Choose a reason for hiding this comment

chrismaree commented Oct 17, 2024

md0x Oct 17, 2024

Choose a reason for hiding this comment

Reinis-FRP Oct 18, 2024

Choose a reason for hiding this comment

md0x left a comment

Choose a reason for hiding this comment

Reinis-FRP left a comment

Choose a reason for hiding this comment

chrismaree Oct 21, 2024

Choose a reason for hiding this comment

pxrl Oct 22, 2024

Choose a reason for hiding this comment

chrismaree commented Oct 11, 2024 •

edited

Loading