Multi-chain SUAVE Request for Ideas

SUAVE
1

In the suave-specs there is currently some discussion on how to enable multi-chain support for SUAVE. I have summarized the conversation so far below in hopes of bringing more visibility to the idea space. :heart:

Problem Statement

  • The current SUAVE implementation is limited to interacting with a single, Dencun Compatible L1 blockchain at a time, restricting its operation in a multi-chain context.
  • There’s a need to generalize the execution namespace within SUAVE to enable execution calls to nodes on any chain supporting this namespace.

Design Goals

  • Multi-Chain Compatibility: Enable SUAVE to seamlessly interact with multiple blockchain networks whose nodes support the execution namespace.
  • Flexible Payload Crafting: Develop a mechanism within SUAVE for efficiently crafting and managing payloads for different chains.

Challenge

  • Ensuring a SUAPP is aware of the execution services a kettle exposes is challenging, especially when dealing with encrypted CCRs and the need for smart contracts to craft payloads flexibly using JSON RPC requests through the doHttpRequest precompile.

Proposed Solutions and Discussions

  • Multichain Compatibility:
    • Suggestion to allow suave.eth.remote_endpoint to support comma-separated strings in the format chainId:rpc_url, enabling SUAVE to reroute remote RPC requests to the appropriate URL based on the chain ID.
    • Modification of the buildEthBlock precompile to include a chain ID parameter, enabling users to specify the destination chain for block construction.
  • Flexible Payload Crafting:
    • Generalizing the buildEthBlock precompile to remove the need for specifying buildBlockArgs, with the payload attributes being handled by the RPC remote backend.
    • The necessity to modify sequencers for chains with a single trusted sequencer to share payload attributes.
  • Challenges and Considerations:
    • Whether all kettles need to connect to multiple chains and the social consensus on-chain ID to chain mapping.
    • A different approach suggests deprecating certain endpoints in favor of building functionality using Solidity and the arbitrary HTTP precompile in suave-std as another protocol.
    • The idea of a name resolve service on the MEVM for the arbitrary HTTP endpoint, allowing for more flexible and secure endpoint specifications.
  • Security and Extensibility Concerns:
    • Concerns about allowing arbitrary URLs in contracts due to potential leaks of confidential information.
    • Proposals for a DNS-like approach to offer a more extensible solution than chain ID mapping, potentially allowing multiple RPC endpoints per chain.
7 Likes
2

The rpc_url in such cases can be a bundler URL, that will ensure leveraging account abstraction, gas abstraction (using paymasters) and retaining the decentralisation (post the launch of shared mempool)?

On a separate note, will suave be open to supporting RIP7560?

1 Like
3

Yes, I love this idea! So perhaps one thing we may need to add to the suggested “SUAVE Domain Name Service” is which RPC spec it implements.

I haven’t deep-dived into this RIP yet, but from a quick glance, we would be extremely interested in supporting RIP7560 and acting as an early testbed for this line of R&D!

2 Likes
4

This will be awesome.

5

this would be my suggestion, as there’s a need for a something like a ‘suave CA’ & CRL` to do things like tcb recovery. This need exists outside of multi-chain: e.g., a kettle could ratls attest a non-suave sgx node (off chain / cross-chain).

:idea:

let’s say you go with ens:

Kettles are bootstrapped with a DKG ceremony. This key is the rootCA, and itgets refreshed every epoch. In order for nodes to continue to ‘stake’ (stay on the cool list), their isvEnclaveQuoteStatus needs to return OK.

this rootCA will sign certs of new nodes attempting to join the swarm. you get slashed if your node is anything but isvEnclaveQuoteStatus() === OK.

so each node would be named, per epoch:

p2pidentitypubkey.isvEnclaveQuoteStatus().suave.eth

e.g.,:

ridgil
b8e1…cfef.group_out_of_date.suave.eth
9d03…cfd.group_out_of_date.suave.eth
cd83…f4f.key_revoked.suave.eth
846f…68a.ok.suave.eth
141f…756.ok.suave.eth

on second thought – none of this is needed; it should all be done on-chain