feat: address to bytes32 contract changes #650

md0x · 2024-10-10T11:24:42Z

Changes proposed in this PR:

Move addresses to bytes32 to support SVM

Signed-off-by: Pablo Maldonado <[email protected]>

md0x · 2024-10-10T11:29:03Z

contracts/SpokePool.sol

        uint32 quoteTimestamp,
        uint32 fillDeadline,
        uint32 exclusivityPeriod,
        bytes calldata message
    ) public payable override nonReentrant unpausedDeposits {
        // Check that deposit route is enabled for the input token. There are no checks required for the output token
        // which is pulled from the relayer at fill time and passed through this contract atomically to the recipient.
-        if (!enabledDepositRoutes[inputToken][destinationChainId]) revert DisabledRoute();
+        if (!enabledDepositRoutes[inputToken.toAddress()][destinationChainId]) revert DisabledRoute();


Should we changed the data structure to:

mapping(bytes32 => mapping(uint256 => bool)) public enabledDepositRoutes;

I think yes, as that would avoid unnecessary conversion, and it would still use the same storage slot for the mapped values.

Signed-off-by: Pablo Maldonado <[email protected]>

Reinis-FRP · 2024-10-10T12:37:47Z

contracts/SpokePool.sol

        bytes calldata updatedMessage,
        bytes calldata depositorSignature
    ) public override nonReentrant {
        _verifyUpdateV3DepositMessage(
-            depositor,
+            depositor.toAddress(),


maybe also update _verifyUpdateV3DepositMessage interface so we don't need to translate to address here

contracts/SpokePool.sol

Reinis-FRP · 2024-10-10T13:14:33Z

contracts/libraries/AddressConverters.sol

+pragma solidity ^0.8.0;
+
+library Bytes32ToAddress {
+    function toAddress(bytes32 _bytes32) internal pure returns (address) {


should this also check that highest 12 bytes are all 0? Also, we should avoid using this method in comparisons where possible and convert the other value to bytes32 first

do you think that will get too expensive gas-cost wise? Maybe we can have safeToAddress and unsafeToAddress and use them depending on the context

Extra gas consumption associated with this check, this accounts for all the toAddress() calls in each of this functions:
depositV3: +128 gas units (from 100832 to 100960)
fillV3Relay: +156 gas units (from 109071 to 109227)

I think it's negligable, wdyt?

Reinis-FRP · 2024-10-10T13:17:35Z

contracts/SpokePool.sol

@@ -979,7 +1009,7 @@ abstract contract SpokePool is
    ) public override nonReentrant {
        V3RelayData memory relayData = slowFillLeaf.relayData;

-        _preExecuteLeafHook(relayData.outputToken);
+        _preExecuteLeafHook(relayData.outputToken.toAddress());


shall we also change this _preExecuteLeafHook

chrismaree · 2024-10-10T16:44:29Z

contracts/SpokePool.sol

@@ -141,9 +146,12 @@ abstract contract SpokePool is
    // token for the input token. By using this magic value, off-chain validators do not have to keep
    // this event in their lookback window when querying for expired deposts.
    uint32 public constant INFINITE_FILL_DEADLINE = type(uint32).max;
-    /****************************************


you might not have meant to modify bits like this?

No, I have some issues with the formatter, I will try to fix my formatter or manually revert this changes

chrismaree · 2024-10-10T16:47:02Z

contracts/libraries/AddressConverters.sol

+}
+
+library AddressToBytes32 {
+    function toBytes32(address _address) internal pure returns (bytes32) {


I like this. we should re-use it here as well:

contracts/contracts/libraries/CircleCCTPAdapter.sol

Line 71 in 5f08c27

function _addressToBytes32(address addr) internal pure returns (bytes32) {

chrismaree · 2024-10-10T16:47:41Z

contracts/SpokePool.sol

@@ -37,6 +38,8 @@ abstract contract SpokePool is
 {
    using SafeERC20Upgradeable for IERC20Upgradeable;
    using AddressLibUpgradeable for address;
+    using Bytes32ToAddress for bytes32;


this is actually pretty clean. good job.

Co-authored-by: Reinis Martinsons <[email protected]>

Signed-off-by: Pablo Maldonado <[email protected]>

…otocol/contracts into pablo/address-to-bytes32

Signed-off-by: Pablo Maldonado <[email protected]>

pxrl · 2024-10-15T12:53:06Z

contracts/SpokePool.sol

@@ -225,8 +233,9 @@ abstract contract SpokePool is
     * @param payoutAdjustmentPct Adjustment to the payout amount.
     */
    /// @custom:audit FOLLOWING STRUCT TO BE DEPRECATED
+
    struct RelayExecutionInfo {


This data isn't actually used by the contracts and is only kept to give third-parties some way of scraping pre-v3 events. Updating the types here would defeat that purpose. But...it's been >6 months since any of these types/events were actually supported by the contracts. @nicholaspai @mrice32 Thoughts on just removing them?

Speculative PR here: #663

pxrl · 2024-10-15T12:56:06Z

contracts/SpokePool.sol

+            msg.sender.toBytes32(),
+            recipient.toBytes32(),
+            originToken.toBytes32(),


I think this is good; deposit() should ultimately be removed so there's no need for it to actually support bridging to SVM chains. Limiting it in this way is actually a good carrot to encourage people to get off deposit().

pxrl · 2024-10-15T13:00:22Z

contracts/SpokePool.sol

@@ -836,9 +864,9 @@ abstract contract SpokePool is
        // Exclusivity deadline is inclusive and is the latest timestamp that the exclusive relayer has sole right
        // to fill the relay.
        if (


I have a PR here that factors this out to a function. Seems like that will go in, so it might be worth considering that here (it should permit a slight simplification of your change).

Thanks, @pxrl. I can merge your changes once you merge them.

Signed-off-by: Pablo Maldonado <[email protected]>

chrismaree · 2024-10-17T08:55:11Z

test/evm/hardhat/fixtures/SpokePool.Fixture.ts

@@ -449,7 +450,7 @@ export async function getUpdatedV3DepositSignature(
        { name: "depositId", type: "uint32" },
        { name: "originChainId", type: "uint256" },
        { name: "updatedOutputAmount", type: "uint256" },
-        { name: "updatedRecipient", type: "address" },
+        { name: "updatedRecipient", type: "bytes32" },


contracts/Polygon_SpokePool.sol

Signed-off-by: Pablo Maldonado <[email protected]>

Reinis-FRP · 2024-10-18T12:24:36Z

contracts/SpokePool.sol

@@ -1039,16 +1237,17 @@ abstract contract SpokePool is
        SpokePoolInterface.RelayerRefundLeaf memory relayerRefundLeaf,
        bytes32[] memory proof
    ) public payable virtual override nonReentrant {
-        _preExecuteLeafHook(relayerRefundLeaf.l2TokenAddress);
+        _preExecuteLeafHook(relayerRefundLeaf.l2TokenAddress.toBytes32());


Is there a reason we cannot change SpokePoolInterface.RelayerRefundLeaf interface to use bytes32 for l2TokenAddress?

I kept it to prevent extra castings in the _distributeRelayerFunds function but you are right, I think these are negligible so I've updated the interface now.

Reinis-FRP · 2024-10-18T12:31:03Z

contracts/Linea_SpokePool.sol

@@ -15,6 +15,7 @@ import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
 */
 contract Linea_SpokePool is SpokePool {
    using SafeERC20 for IERC20;
+    using AddressToBytes32 for address;


nit: shall we use explicit imports? I see that recent commits have been moving in that direction.

Sorry @Reinis-FRP What do you mean here?
These are imported in the SpokePool.sol and used here

sorry, meant using curly braces to explicitly state what contracts/libraries from source files we are importing

Reinis-FRP · 2024-10-18T12:55:52Z

contracts/SpokePool.sol

+        );
+    }
+
+    function _verifyUpdateV3DepositMessage(


nit: could add comment why we need this internal overload and cannot convert to address at the outer function. I assume this has to do with different hash. Alternatively, we could change the interface of _verifyUpdateV3DepositMessage to include hash type so that outer method could pass it through without needing overload on internal method.

See my answer here: https://github.com/across-protocol/contracts/pull/650/files#r1808446450

Reinis-FRP · 2024-10-18T13:08:12Z

contracts/SpokePool.sol

+        bytes memory updatedMessage,
+        bytes memory depositorSignature
+    ) internal view {
+        _verifyUpdateV3DepositMessageHelper(


do we really need this extra helper? might be simpler to change the interface of _verifyUpdateV3DepositMessage to accept additional hashType parameter (see comment above).

_verifyUpdateV3DepositMessage is also overloaded with 2 implementations, one for address and one for bytes32. I added the helper to reduce code duplication. Without it each _verifyUpdateV3DepositMessage would need to implement _hashTypedDataV4(keccak256(abi.encode... having this logic duplicated. Does it make sense?

I meant avoiding overload in _verifyUpdateV3DepositMessage and let its caller in the external function to do address->bytes32 conversion when needed, as well as pass the relevant hashType from constants.

Reinis-FRP · 2024-10-18T13:15:20Z

contracts/erc7683/ERC7683.sol

@@ -6,10 +6,10 @@ pragma solidity ^0.8.0;
 struct GaslessCrossChainOrder {
    /// @dev The contract address that the order is meant to be settled by.
    /// Fillers send this order to this contract address on the origin chain
-    address originSettler;
+    bytes32 originSettler;


Does this require any changes in ERC proposal?

yes. the ERC itself. is being updated by Matt and others.

Reinis-FRP · 2024-10-18T13:18:09Z

contracts/interfaces/V3SpokePoolInterface.sol

+        uint32 exclusivityDeadline,
+        bytes calldata message
+    ) external payable;
+
    function depositV3(
        address depositor,


Do we need to support backwards overload in the interface?

Good point. I've removed them from the interface 👍

Reinis-FRP · 2024-10-18T13:21:36Z

contracts/libraries/CircleCCTPAdapter.sol

@@ -88,7 +81,7 @@ abstract contract CircleCCTPAdapter {
     * @param amount Amount of USDC to transfer.
     */
    function _transferUsdc(address to, uint256 amount) internal {
-        _transferUsdc(_addressToBytes32(to), amount);
+        _transferUsdc(to.toBytes32(), amount);


neat that we can reuse the lib here :)

chrismaree · 2024-10-18T14:33:54Z

contracts/SpokePool.sol

+     * If the depositor is a contract, it should implement EIP1271 to sign as a contract. See `_verifyUpdateV3DepositMessage()`
+     * for more details on how the signature should be constructed.
+     */
+    function speedUpV3Deposit(


question: is it useful to have both this address and bytes versions? do we expect intergrators (UIs) to call the address or bytes version? the context of my question is that seeing we wont support speedup on svm domain (requiring bytes32) is it useful to have this?

I think yes: we should have it, as we can then support it going forward and be consistent with the interface changes , but just through I'd bring it up to see what you think.

I think so! But open to remove them if someone disagrees.

chrismaree · 2024-10-18T14:35:32Z

contracts/SwapAndBridge.sol

    function _checkSwapOutputAndDeposit(
        uint256 swapTokenAmount,
        uint256 swapTokenBalanceBefore,
        uint256 inputTokenBalanceBefore,
        uint256 minExpectedInputTokenAmount,
        DepositData calldata depositData,
-        IERC20 _swapToken,
-        IERC20 _acrossInputToken
+        bytes32 _swapToken,


I know this is not your change, but its funny to me that these two variables are _ and the others are not.

Signed-off-by: Pablo Maldonado <[email protected]>

contracts/SpokePool.sol

Signed-off-by: Pablo Maldonado <[email protected]>

md0x added 2 commits October 10, 2024 12:24

feat: add address to bytes32 contract changes

7a5dc8c

Signed-off-by: Pablo Maldonado <[email protected]>

refactor: remove todos

b65940d

Signed-off-by: Pablo Maldonado <[email protected]>

md0x commented Oct 10, 2024

View reviewed changes

refactor: imports

429affc

Signed-off-by: Pablo Maldonado <[email protected]>

Reinis-FRP reviewed Oct 10, 2024

View reviewed changes

contracts/SpokePool.sol Outdated Show resolved Hide resolved

Reinis-FRP reviewed Oct 10, 2024

View reviewed changes

chrismaree reviewed Oct 10, 2024

View reviewed changes

md0x and others added 4 commits October 10, 2024 18:19

Update contracts/SpokePool.sol

3f92876

Co-authored-by: Reinis Martinsons <[email protected]>

feat: bytes 32 comparisons

0873145

Signed-off-by: Pablo Maldonado <[email protected]>

refactor: format code

73f378c

Signed-off-by: Pablo Maldonado <[email protected]>

Merge branch 'pablo/address-to-bytes32' of ssh://github.com/across-pr…

1d5a084

…otocol/contracts into pablo/address-to-bytes32

chrismaree mentioned this pull request Oct 14, 2024

feat: Add relayer repayment address #653

Merged

md0x added 3 commits October 14, 2024 18:22

fix: tests

8f233fa

Signed-off-by: Pablo Maldonado <[email protected]>

feat: bytes 32 check

1a1815b

Signed-off-by: Pablo Maldonado <[email protected]>

fix: ts

64a2291

Signed-off-by: Pablo Maldonado <[email protected]>

md0x changed the base branch from master to svm-dev October 15, 2024 11:23

feat: reuse lib in cctp adapter

209f645

Signed-off-by: Pablo Maldonado <[email protected]>

md0x changed the base branch from svm-dev to svm-development October 15, 2024 11:34

md0x changed the base branch from svm-development to svm-dev October 15, 2024 11:34

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

pxrl reviewed Oct 15, 2024

View reviewed changes

md0x added 3 commits October 16, 2024 12:33

feat: _preExecuteLeafHook

59f294c

Signed-off-by: Pablo Maldonado <[email protected]>

Merge branch 'master' into pablo/address-to-bytes32

1551d32

refactor: comments

74be13c

Signed-off-by: Pablo Maldonado <[email protected]>

chrismaree reviewed Oct 17, 2024

View reviewed changes

md0x changed the title ~~feat: add address to bytes32 contract changes~~ feat: address to bytes32 contract changes Oct 17, 2024

md0x marked this pull request as ready for review October 17, 2024 09:00

chrismaree reviewed Oct 17, 2024

View reviewed changes

contracts/Polygon_SpokePool.sol Show resolved Hide resolved

md0x added 5 commits October 17, 2024 12:39

feat: _verifyUpdateV3DepositMessage

039c323

Signed-off-by: Pablo Maldonado <[email protected]>

feat: backward compatibility

ddfa612

Signed-off-by: Pablo Maldonado <[email protected]>

Merge branch 'svm-dev' into pablo/address-to-bytes32

a20e6ed

feat: backwards compatibility tests

8ee4c76

Signed-off-by: Pablo Maldonado <[email protected]>

feat: change comparison casting address bytes32

6cd2ea2

Signed-off-by: Pablo Maldonado <[email protected]>

Reinis-FRP reviewed Oct 18, 2024

View reviewed changes

chrismaree reviewed Oct 18, 2024

View reviewed changes

md0x added 2 commits October 21, 2024 10:36

fix: test

1ea1344

Signed-off-by: Pablo Maldonado <[email protected]>

feat: merkle tree leaf to bytes32

c91dcb1

Signed-off-by: Pablo Maldonado <[email protected]>

md0x commented Oct 21, 2024

View reviewed changes

contracts/SpokePool.sol Show resolved Hide resolved

md0x commented Oct 21, 2024

View reviewed changes

contracts/SpokePool.sol Show resolved Hide resolved

test: leaf type update fixes

48e4023

Signed-off-by: Pablo Maldonado <[email protected]>

md0x requested review from chrismaree, pxrl and Reinis-FRP October 21, 2024 11:19

feat: remove helper

8412ca9

Signed-off-by: Pablo Maldonado <[email protected]>

Reinis-FRP approved these changes Oct 21, 2024

View reviewed changes

md0x merged commit 5a54ddb into svm-dev Oct 21, 2024
9 checks passed

md0x deleted the pablo/address-to-bytes32 branch October 21, 2024 12:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: address to bytes32 contract changes #650

feat: address to bytes32 contract changes #650

md0x commented Oct 10, 2024 •

edited

Loading

md0x Oct 10, 2024

Reinis-FRP Oct 10, 2024

Reinis-FRP Oct 10, 2024

Reinis-FRP Oct 10, 2024

nicholaspai Oct 15, 2024

md0x Oct 16, 2024

Reinis-FRP Oct 10, 2024

chrismaree Oct 10, 2024

md0x Oct 10, 2024

chrismaree Oct 10, 2024

chrismaree Oct 10, 2024

pxrl Oct 15, 2024

pxrl Oct 15, 2024

pxrl Oct 15, 2024

md0x Oct 17, 2024 •

edited

Loading

chrismaree Oct 17, 2024

Reinis-FRP Oct 18, 2024

md0x Oct 21, 2024

Reinis-FRP Oct 18, 2024

md0x Oct 21, 2024

Reinis-FRP Oct 21, 2024

Reinis-FRP Oct 18, 2024

md0x Oct 21, 2024

Reinis-FRP Oct 18, 2024

md0x Oct 21, 2024 •

edited

Loading

Reinis-FRP Oct 21, 2024

Reinis-FRP Oct 18, 2024

chrismaree Oct 18, 2024

Reinis-FRP Oct 18, 2024

md0x Oct 21, 2024

Reinis-FRP Oct 18, 2024

chrismaree Oct 18, 2024

md0x Oct 21, 2024 •

edited

Loading

chrismaree Oct 18, 2024

feat: address to bytes32 contract changes #650

feat: address to bytes32 contract changes #650

Conversation

md0x commented Oct 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

md0x Oct 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

md0x Oct 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

md0x Oct 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

md0x commented Oct 10, 2024 •

edited

Loading

md0x Oct 17, 2024 •

edited

Loading

md0x Oct 21, 2024 •

edited

Loading

md0x Oct 21, 2024 •

edited

Loading