Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete SCW Support #1070

Closed
8 tasks done
neekolas opened this issue Sep 17, 2024 · 1 comment
Closed
8 tasks done

Complete SCW Support #1070

neekolas opened this issue Sep 17, 2024 · 1 comment
Assignees

Comments

@neekolas
Copy link
Contributor

neekolas commented Sep 17, 2024

In order to get to a version of Smart Contract Wallet support that is developer-friendly and reliable, we need to make a few more changes.

The Problem

The way we verify Smart Contract Wallet signatures right now is exclusively via EIP-6492. That allows us to use one chain_rpc_url for a chain of the developer's choosing and verify signatures there, even if the SCW was created on another chain. This opens up an important edge case that can lead to clients receiving different results for the same signature. In 6492, if the smart contract has been deployed on the chain, it will use the latest state of the contract on that chain to validate the signature. So, if I have a multi-sig and have modified the allowed signers on Base, but you are trying to validate it on Arbitrum, we will get different results. Results are only consistent if the SCW has not been updated since deploying.

Already deployed Smart Contract Wallets will also produce EIP-1271 signatures instead of 6492 signatures as they are much more compact. 6492 signatures include the entire smart contract alongside the signature. That requires access to the chain that the smart contract wallet was deployed to.

Solution

The right way to verify these signatures is to have a chain_rpc_url for each of the XMTP supported chains. We will need a new implementation of SmartContractSignatureVerifier that handles multiple chains (maybe called MultiChainSignatureVerifier. It should contain a mapping of chain_id to RpcSmartContractWalletVerifiers and select the right verifier based on the chain_id.

This will give consistent results between clients, but comes with a significant piece of developer overhead: now you need to have a RPC URL for all chains supported by XMTP.

My suggestion is to also allow for a RemoteSmartContractSignatureVerifier that outsources signature verification to the server, so that we can run a service as a public good that verifies 1271 and 6492 signatures. This service can be available on our nodes, and proxy requests to the mls_validation_service which will use the same MultiChainSignatureVerifier struct that is available on the client.

Tasks

  1. neekolas
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants