This post is taking part in the Lens x Kiwi Writing Contest.
I have ETH on Base but I want to play a game on Mode which is currently impossible without a serires of complex bridge actions. Interoperability removes these barriers, unlocking the full potential of the Layer 2 ecosystem. A user should not care what chain their game or financial asset is on to use Ethereum.
For the end user, interoperability means a smoother, more intuitive experience where it no longer matters which chain their assets reside on; they can be used seamlessly across different rollups. This greatly reduces fees by eliminating the need for complex bridges, resulting in cheaper transactions. With faster cross-rollup communication, users also experience less waiting time and reduced slippage, thanks to unified liquidity pools that provide better pricing. The process of bridging assets is either eliminated or becomes so seamless that it feels like a single, integrated transaction, enhancing overall usability.
For developers, L2 interoperability simplifies the process of building cross-chain applications by removing the need to develop complex bridge logic, allowing them to focus more on product development. This makes it easier to reach a broader audience since applications can be accessed by users across all participating rollups. Developers can also leverage the strengths of each rollup, such as lower fees or unique dApps, and collaborate across chains, opening up opportunities for creative projects like integrating an onchain game with a DeFi product.
On a broader level, the ecosystem benefits greatly from interoperability as it encourages network growth through shared infrastructure and a more interconnected user base. This interconnectedness accelerates innovation, as collaboration between developers on different chains leads to the creation of more advanced use cases. Additionally, interoperability increases the utility of tokens, as they can operate across multiple chains, reaching more liquidity and user engagement points.
Shared Validity Sequencing (SVS) offers a novel solution to these challenges by creating a unified system of transaction ordering and verification across multiple rollups. It allows rollups to share a globally valid transaction history, eliminating the need for third-party services and enabling token transfers that are fast, secure, and efficient.
When users move tokens between Layer 2 rollups, they typically interact with a bridge, which locks tokens on the source rollup and unlocks or mints corresponding tokens on the destination rollup. Here’s a simplified version of the bridging process:
- Locking Tokens: The user locks or burns tokens on Rollup A, signaling that they want to move the assets to Rollup B.
- Message to the Bridge: The user sends a transaction to a bridge smart contract, which acts as an intermediary, verifying the locked tokens on Rollup A.
- Waiting for Confirmation: Rollup B needs to verify the finality of the transaction on Rollup A, often waiting for multiple confirmations to prevent any potential rollback or reorganization of the source chain.
- Minting Tokens: After verification, the bridge mints or unlocks equivalent tokens on Rollup B.
This process is not only time-consuming but also relies on third-party relayers or validators. These external entities introduce additional costs and potential vulnerabilities. Bridges have been a frequent target for hacks, underscoring the security risks involved in cross-chain transfers.
Under SVS, Rollup A and Rollup B both reference the same shared global transaction sequence and rely on a shared validity layer to ensure consistency across rollups. This system provides cross-rollup compatibility, allowing tokens to be transferred seamlessly without any external validators or validators involved
Here’s how token transfers work with SVS:
- Transaction on Rollup A: The user initiates a transfer by locking or burning their tokens on Rollup A. This transaction is not only processed by Rollup A but also included in the shared transaction sequence that both Rollup A and Rollup B can see.
- Shared Transaction History: Since both rollups reference the same shared sequence, Rollup B immediately knows about the transaction on Rollup A. There is no need for an external bridge or relayer to communicate the intent of the transfer.
- Token Release on Rollup B: After confirming that tokens were locked on Rollup A through the shared sequence, Rollup B mints or releases the equivalent amount of tokens. The entire process is governed by the cryptographic proofs embedded in the shared validity layer, which ensures that Rollup B can trust the transaction without additional verification steps.
In the Shared Validity Sequencing (SVS) framework, each rollup maintains both a local and global transaction sequence, which work together to ensure efficient processing of transactions within individual rollups and across the broader Superchain ecosystem.
Local Transaction Sequence: This is the transaction history specific to each rollup, handling operations that are confined to that particular chain. For example, simple token transfers, swaps, or gaming interactions that occur on one chain, are managed within the local transaction sequence. This allows each rollup to process transactions independently, maximizing efficiency and speed.
Global Transaction Sequence: The global sequence, on the other hand, tracks transactions that involve cross-rollup interactions. When you transfer ETH from Base to Mode or when an in-game action requires assets from another rollup, this transaction is included in the global sequence. Both chains reference this shared global transaction history, ensuring consistent state across all participating rollups.
When a user initiates a transaction on one chain that doesn’t involve another rollup, it stays within the local sequence—this makes it quick and efficient.
If the transaction needs to be recognized by another rollup (e.g., transferring ETH to a differnt L2 for gameplay), it’s recorded in the global transaction sequence, which both rollups can see and trust. This dual-sequencing model enables rollups to operate independently for most tasks while maintaining seamless interoperability for cross-rollup actions. The result is an ecosystem that’s both scalable and interconnected, allowing for efficient processing of localized transactions without sacrificing the ability to interact across the entire Layer 2 network.
To demonstrate how Shared Validity Sequencing (SVS) enhances user experience, let's walk through a scenario where you hold ETH on Chain A (Base) and want to use it to play a game on Chain B (Mode). This process highlights how SVS makes cross-rollup interactions seamless, secure, and efficient compared to traditional bridging methods.
You hold ETH on Chain A (Base) and want to use that ETH to interact with a game on Chain B (Mode). Normally, transferring ETH between these rollups would involve using a bridge, introducing delays, complexity, and additional costs. With SVS, however, the process is streamlined. Here’s how it works:
You have ETH on Chain A (Base) and decide to use it for in-game purchases or to participate in gameplay on Chain B (Mode). To enable this, you need to transfer your ETH from Chain A to Chain B.
Under the Shared Validity Sequencing (SVS) framework, instead of relying on a traditional bridge, you initiate a burn or lock transaction on Chain A (Base). This action signals that the ETH is no longer available for use on Chain A and will be transferred to Chain B (Mode).
Transaction Details:
- Locking or burning ETH on Chain A: This transaction locks your ETH on Chain A (Base) and is included in the shared global transaction sequence, visible to both rollups.
Once the ETH is burned on Chain A (Base), this event is immediately recognized by both Chain A and Chain B (Mode) through the shared global transaction sequence.
- No relayer or bridge is needed to communicate this transfer. Chain B can directly reference the shared transaction history to confirm the lock on Chain A.
Since Chain B (Mode) trusts the shared validity layer, it knows the ETH on Chain A has been locked or burned and is now available for release on Chain B.
Key Points:
- Shared Global Sequence: Both chains access the same transaction history.
- Instant Recognition: Chain B recognizes the transfer as soon as it’s confirmed on Chain A.
ETH becomes available on Chain B (Mode). Once Chain B confirms through the shared sequence that the ETH was locked on Chain A (Base), it "mints" or releases the equivalent amount of ETH on Chain B.
Now, your ETH is available on Chain B without requiring any external validators or bridges. You can use this ETH to interact with the game on Mode, such as buying in-game items, paying for gameplay, or participating in the game’s ecosystem.
With your ETH now on Chain B (Mode), you’re ready to engage with the game. The ETH you transferred can be used to purchase items, pay for game actions, or interact with other in-game assets, all in a straightforward manner.
- You make in-game transactions using the ETH available on Chain B, just as if you were originally holding ETH on that chain. The experience is smooth, as there’s no need for any additional steps or bridging mechanisms.
Both chains remain synchronized: Since both Chain A (Base) and Chain B (Mode) reference the shared global transaction sequence, they stay updated on the transfer of ETH. There’s no need for further reconciliation, and your gaming experience on Chain B is uninterrupted.
Outcome: You successfully used ETH from Base to participate in a game on Mode in a secure, efficient, and cost-effective way, without the complexities and delays of traditional bridges.
SVS transforms what would be a multi-step, costly, and time-consuming process into an instant, secure, and user-friendly experience, making it easier to interact on Ethereum with the scaling and affordances offered by Layer 2s.
- You’d have to use a bridge to lock ETH on Chain A.
- A bridge would verify the transaction, requiring third-party relayers.
- You’d wait for the bridge to mint ETH on Chain B.
- This process would take longer due to multiple layers of verification and incur higher transaction fees.
- You lock ETH on Chain A, which is immediately recognized by Chain B via the shared transaction sequence.
- Chain B releases ETH without any bridge, relayer, or third-party protocol.
- The process is fast, secure, and cheaper, as it reduces reliance on external validators and eliminates redundant verification.
With Shared Validity Sequencing (SVS), there's no need for traditional bridges, which are often slow and susceptible to security vulnerabilities. SVS removes this dependency by keeping both rollups synchronized through a shared validity layer and a global transaction history, significantly reducing the risk of inconsistencies. This shared system also ensures faster finality, as transactions are processed and verified much more quickly, thanks to the unified global transaction sequence that both chains use, resulting in a more efficient and secure cross-rollup transfer process.
In summary, with Shared Validity Sequencing, transferring ETH, tokens and other assets between rollups to interact across chains becomes seamless and efficient. The elimination of bridges and reliance on shared sequencing results in a faster, more secure, and cheaper process.
Shared Validty Sequncing was designed by Umbra and is the current approach being explored by Optimism. There is no release date for this but there is a lot of effort on it and I'm hopefully we will all be transaction seamlessly across chains in the next 12 months.
Thanks to @phil, @naomiii and @macbudkowski for Feedback and edits and to Sandman from Delphi Research for this research report on the various approaches to Layer 2 interoperability.