Generalize SUAVE Execution Namespace

[dmarzzz]

Problem Statement

The current implementation of SUAVE is limited to interacting with Dencun Compatible L1 blockchains and only supports one chain at a time. This limitation restricts SUAVE to operate in a multi-chain manner. The Open Question is how to generalize the execution namespace within SUAVE to enable routing execution calls to nodes on any chain supporting this namespace.

https://github.com/flashbots/suave-specs/blob/main/specs/rigil/mevm.md#suavex-namespace

Design Goals

1. Multi-Chain Compatibility: Enable SUAVE to interact seamlessly with multiple blockchain networks with nodes that support the execution namespace.

2. Flexible Payload Crafting: Develop a system within SUAVE to efficiently craft and manage payloads for different chains .

Challenge

1. One of the main challenges is that a SUAPP must be aware of the execution services that the kettle exposes. For example, a SUAPP that uses Eth L1 and Optimism Execution Nodes should fail when it attempts to be run on a Kettle that only supports Eth L1. Even further, a kettle should simply not even attempt to serve this RPC request, which is even tougher considering CCRs are eventually encrypted.
2. One important consideration is the eventual capability to send JSON RPC requests for buildEthBlock using the doHttpRequest precompile, which allows the smart contract to craft the payload flexibly and require less defined at the SUAVE protocol and precompile layer.

[jinmel]

Problem

Current suave-geth allows only one rpc backend and the buildEthBlock precompile focuses on L1(Ethereum) blocks only. In an attempt to expand suave's capability to talk with multiple chains (L2s or any ethereum compatible chain), suave must support connecting to multiple rpc backends and precompiles that talks to rpc backend (buildEthBlock, simulateBundle, ...) should account for their differences in protocol

Design

Multichain compatibility

1. suave.eth.remote_endpoint allows comma separated strings in following format chainId:rpc_url. Suave will maintain an internal registry to reroute remote rpc requests to a chain designated by chainId to the corresponding rpc_url.
2. buildEthBlock should change it's signature to buildEthBlock(chainId, buildBlockArgs, dataId, namespace) so that user can set on which destination chain block should be built.

Flexible Payload crafting

Generalizing buildEthBlock

As long as the destination chain is compatible with ethereum, the payload attributes can be handled at the rpc remote backend itself. This allows:

• The caller of buildEthBlock precompile does not need to care about the buildBlockArgs for the next block.
• Removing buildBlockArgs makes the buildEthBlock Caveats:
• If the destination chain has uses single trusted sequencer, we need to modify the sequencer to share payload attributes for the next block.

Challenges

1. Does it require ALL kettles to connect to multiple chains?
2. Social consensus on chain id to chain mapping

[ferranbt]

I have a different approach for the problem.

buildEthBlock should change it's signature to buildEthBlock(chainId, buildBlockArgs, dataId, namespace) so that user can set on which destination chain block should be built.

My goal is to deprecate these endpoints altogether because they can be built using Solidity + the arbitrary http precompile in suave-std as another protocol.

Note that this change also implies that we do not have anymore a suave.eth.remote_endpoint since that would be a param on the Solidity call. This is an early experiment I did for the simulateBundle precompile.

suave.eth.remote_endpoint allows comma separated strings in following format chainId:rpc_url. Suave will maintain an internal registry to reroute remote rpc requests to a chain designated by chainId to the corresponding rpc_url.

Following the previous point, this can be generalised as a name resolve service on the MEVM for the arbitrary HTTP endpoint.

suave-geth --suave.dns goerlisuavex=https://goerli.rigil.flashbots.net

and then you can do:

Suavex.simulateTxn("goerlisuavex", ...)

[jinmel]

I thought it should be the kettle operator running the rpc to keep everything under TEE. So I assumed setting arbitrary urls in contract should be forbidden. Otherwise someone might leak confidential store to his own endpoint. I think the dns approach sounds more extensible than chain id because now you can have multiple rpc endpoint per chain. i.e.) goerli-1, goerli-2. not sure if it is necessary to have multiple endpoints.

[dmarzzz]

Yeah there is a friction here good call out @jinmel . when reading a suave contract we need to be able to guarantee that the URL someone is using to simulate is the kettle's domain service (or another kettle's domain service). I think with what @ferranbt recommended this is possible.

also I like the idea of multiple endpoints per chain, sims can likely arbitrarily scale so this will be good to support, the main thing we will need to abstract away though in the multi domain setting is making sure sessions with "connection IDs" continue to use the same endpoint. Perhaps we can do this as follow on work and just assume 1 endpoint per chain for now.

[jinmel]

in your scenario @ferranbt, does the kettle operator set the whitelisted url endpoints that suapps can talk with? I am mildly concerned about the security of user setting arbitrary raw url. This is literally one loop hole where everything can be leaked out.

[jinmel]

@dmarzzz do you mean the builder sessions? I think that can be easily managed in the next PR.

[ferranbt]

in your scenario @ferranbt, does the kettle operator set the whitelisted url endpoints that suapps can talk with? I am mildly concerned about the security of user setting arbitrary raw url. This is literally one loop hole where everything can be leaked out.

Yes, it is the kettle that whitelists the addresses. Of course, if the address is set on this dns registry, it is automatically whitelisted.