Exploring SuperSim: Simulating Interoperability on the Superchain with OP Stack

wispy - Oct 30 - - Dev Community

Recently, I had the opportunity to try out a new tool called SuperSim. As a Mode ambassador, I was able to test it and wanted to share my feedback. Given my ongoing research into L2 solutions, particularly the Optimism ecosystem, this tool caught my attention as a potential asset in understanding how L2s function in practice.

In this article, I'll walk you through my experience with SuperSim — from the testing process to the challenges I faced, the lessons I learned, and how all of this deepened my understanding of L2 solutions.

What is SuperSim?

SuperSim is a lightweight tool designed to simulate the Superchain, which consists of a single L1 chain and multiple L2 chains built with the OP-Stack. Its main advantage is simplicity: it allows devs to run multiple local nodes with a single command, significantly easing the coordination of message passing between these chains. Moreover, it does not require complex devnet configurations, as everything is managed through CLI commands that automatically adjust if no configuration options are specified. Each chain operates as an instance of anvil, a widely used testing tool in local environments.

SuperSim enables working with pre-deployed anvil nodes and contracts based on the OP Stack, as well as forking multiple remote chains, which allows for replicating the state of the entire Superchain for more realistic testing. Additionally, it simplifies message simulation between L1 and L2, such as deposits, and interoperability between L2 chains, with a built-in auto-relayer that streamlines communication. It will soon include additional features, such as withdrawals and account abstraction services based on the ERC-4337 standard, like bundlers and paymasters, as well as the implementation of smart wallets.

How was the Developer Experience?

The installation process for SuperSim was quite straightforward since it is built on Foundry, a widely used tool. However, when I attempted to install SuperSim in an Ubuntu environment running on Windows via WSL, I encountered a problem: the provided commands assumed that Homebrew was already installed, which is not the default case on Ubuntu. To resolve this, I installed Linuxbrew, a version of Homebrew for Linux.

If you have Ubuntu and want to install Homebrew to try it out, here’s the link that explains the entire process: Homebrew on Linux

Thanks to this installation, I successfully executed the necessary commands to install SuperSim in my WSL environment.

Once I installed Homebrew, I proceeded with the installation of SuperSim, which turned out to be quite straightforward.

The “First steps” section is the best place to start, which is divided into two sections. The first involves depositing ETH from L1 to L2, and the second involves sending an interoperable SuperchainERC20 token from chain 901 to 902.

1. Deposit ETH from the L1 into the L2 (L1 to L2 message passing)
First, I verified the balance on L2 (chain 901) to ensure I had an accurate starting point. After confirming the balance, I initiated a transaction from L1 (chain 900) by sending 0.1 ether. Once the transaction was completed, I checked the L2 balance again, which had increased accordingly, reflecting the successful transfer.

2. Send an interoperable SuperchainERC20 token from chain 901 to 902 (L2 to L2 message passing)

The goal of this step is to transfer an ERC20 token from one L2 (chain 901) to another L2 (chain 902). Typically, a cross-chain L2 to L2 transfer involves two key transactions:

- Send transaction on the source chain (chain 901): This initiates the token transfer on chain 901. During this transaction, the token is locked on the source chain, and the transfer details are prepared to be sent to the destination chain.

- Relay message transaction on the destination chain (chain 902): Once the transfer details reach chain 902, a transaction on the destination chain is triggered to finalize the token reception. This transaction ensures that the tokens are available on chain 902.

Optimizing with --interop.autorelay
To simplify this process, SuperSim offers the --interop.autorelay flag, automatically triggering the relay message transaction on the destination chain. This removes the need for manually sending the relay message, significantly improving the developer experience.

Here’s what I did:

1. I started SuperSim with the auto-relay mode enabled.
I did this by running the following command:

supersim --interop.autorelay
Enter fullscreen mode Exit fullscreen mode

2. Mint tokens on chain 901 to prepare them for transfer.
I executed the following command to mint 1000 L2NativeSuperchainERC20 tokens to the recipient's address:

cast send 0x420beeF000000000000000000000000000000001 "mint(address _to, uint256 _amount)" 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 1000 --rpc-url http://127.0.0.1:9545 --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

Enter fullscreen mode Exit fullscreen mode

3. Initiate the send transaction on chain 901, transferring the tokens from chain 901 to chain 902.
I did this using the following command:

cast send 0x420beeF000000000000000000000000000000001 "sendERC20(address _to, uint256 _amount, uint256 _chainId)" 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 1000 902 --rpc-url http://127.0.0.1:9545 --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
Enter fullscreen mode Exit fullscreen mode

4. I waited a few seconds for the relay message to appear on chain 902.
Here is the message:

INFO [10-22|13:24:00.942] L2ToL2CrossChainMessenger#RelayedMessage sourceChainID=901 destinationChainID=902 nonce=0 sender=0x420beeF000000000000000000000000000000001 target=0x420beeF000000000000000000000000000000001
Enter fullscreen mode Exit fullscreen mode

5. Finally, I checked the balance on chain 902 to confirm that the tokens had been successfully transferred and that the balance had increased.
I ran the following command to verify the balance:

cast balance --erc20 0x420beeF000000000000000000000000000000001 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 --rpc-url http://127.0.0.1:9546
Enter fullscreen mode Exit fullscreen mode

Following this guide was fairly easy, given that I have been researching how L2s work, particularly in the context of Optimism. If you want to dive deeper into this topic, I recently published an article on optimistic rollups which you can read here.

After completing the "First steps" section, I explored the interoperability guide titled "Message Relay Manual with cast," which describes how to send messages between different blockchain layers. In this guide, we manually transfer SuperchainERC20 tokens without using the automatic relay feature. The process involves starting the transfer on one layer and then sending the necessary message to complete it on the other layer, if you want to better understand what this involves, here's the link so you can try it too.

While following the guide, I encountered an error during the "Send the relayMessage transaction" step:

Error: server returned an error response: error code 3: execution reverted: custom error 0xeda86850, data: "0xeda86850".
Enter fullscreen mode Exit fullscreen mode

Although I double-checked that I was following the steps correctly, the error persisted, and attempts to find solutions using AI were unsuccessful.

I decided to seek support from the Optimism community. I joined the Optimism Discord and asked in the general chat where I could discuss the issue related to SuperSim. There, I was provided with a link to the repository where I could create a discussion.

Upon opening the link, I found several options offering different approaches, some more technical than others, such as "Feedback," "Ideas," "General," and "Developer Questions." First, I identified which category would best fit my situation. Since I didn't find any discussions related to the error I was experiencing in the "Developer Questions" section, I decided to create one in the "General" category.

I added a title that was as descriptive as possible for the problem I was facing and provided detailed, clear, and coherent context regarding my error, ensuring I included all relevant information for others to understand my situation. Finally, I created the discussion outlining the error and the context of my work.

A few days later, I received a response informing me that they had updated the documentation and asked me to check if the problem persisted. To my satisfaction, the error was resolved; it appeared to be an issue with the original documentation. I’m glad it has been corrected, and I can now effectively test SuperSim.

This was my first time creating a discussion on GitHub, and I found it to be an interesting experience. I'm very pleased with the prompt response and quick solution I received.

You can view the complete discussion here. If you'd like to create a discussion, you can do so here.

Learnings and Reflections

Thanks to following the steps in the "First Steps" guide, I successfully bridged ETH from Layer 1 to Layer 2 and transferred an interoperable SuperchainERC20 token between Layer 2, all done locally.

Additionally, while exploring the interoperability guide titled "Message Relay Manual with cast," I learned how to create a message identifier for cross-chain call transmission. This guide outlines the manual message relay process for transferring the SuperchainERC20 token, including key steps such as initiating the transfer on the source chain and relaying the message on the destination chain. This experience has provided me with a broader understanding of interactions between L2s, expanding my knowledge of L2s and the Optimism ecosystem.

In summary, this experience reinforces the importance of interoperability in multi-chain environments and highlights the usefulness of tools like SuperSim to facilitate these interactions.I plan to create content about what I learn and share my insights along the way.

For more details and to try SuperSim, you can check out the official documentation here.

My social media:

x.com/wispyiwnl
warpcast.com/wispyiwnl

. . . . . .