The Good Tech Companies - The State Of Rollup Interoperability Solutions

Episode Date: December 20, 2024

This story was originally published on HackerNoon at: https://hackernoon.com/the-state-of-rollup-interoperability-solutions. An overview of Ethereum interoperability solutions that covers keystore rollups, intent bridges, cross-chain smart accounts, multichain ENS, and more. Check more stories related to web3 at: https://hackernoon.com/c/web3. You can also check exclusive content about #ethereum, #blockchain-interoprability, #ethereum-rollups, #web3, #blockchain, #cross-chain-bridges, #ethereum-layer-2-solutions, #good-company, and more. This story was written by: @2077research. Learn more about this writer by checking @2077research's about page, and for more stories, please visit hackernoon.com. Interoperability is critical to the success of Ethereum's rollup-centric roadmap. This report provides commentary on the state of rollup interoperability—offering insights on existing and proposed solutions to interoperability issues, their limitations, and future improvements to rollup interoperability infrastructure.

However, the area is migrating to account abstraction-based smart accounts. These accounts allow us to add any functionality we want to our wallets programmatically. P256 signatures make it possible to use secure chips in our phones to sign transactions. Through social recovery, we can add our relatives as guardians authorized to recover our wallets, eliminating unsafe seed phrases. Paymaster technology allows us to pay the gas fee in any token or even make someone pay the fee for us. When quantum computers start breaking classic signature schemes, we can just change the scheme in our ah wallets to a quantum safe one without

creating a new wallet. Backslash dot, this list can be continued endlessly, as account abstraction essentially allows US to use executable programs as full-fledged wallets. But all this comes at a cost. One can't easily migrate their wallets to another chain because, besides moving the funds through the bridge, it requires redeploying the entire account with all the keys, guardians, and settings. In some cases, this might be too complicated or even impossible. Say, in rollups that don't support the P256 precompile, this signature scheme might be too expensive to use. This is why I made that protocol. Essentially, you have all accounts on many L2s. To send a transaction from them, you must verify

your intent by sending a hash off it from your main account on a specific L2 to those mini-accounts through the L1 bridge messaging. In fact, this way, you don't get rid of multiple wallets. You simply move all the verification logic to a single, parent, account. Another interesting detail of such a protocol is that it allows for interoperability not only with L2s but with all L1s. Sidechains that have been shrined bridges with Ethereum, Polygon POS, Ronin, Gnosis, and Avalanche are what I can think of. However, it was designed as a roll-up-centric interoperability protocol, so this is just a fun technological fact. While the idea of the project

was pretty clever, the practical implementation had a significant drawback. Speed. The entire design relies on canonical roll-up bridges connected to Ethereum L1. Roll-up bridges are peculiar in that they probe their state to their smart contracts on Ethereum to inherit its security. As you may already know, optimistic and ZK verification are the two most popular ways to do this. Optimistic verification works by opening a challenge window, usually about 7 days, in which the challengers can send a fraud proof that points to any invalid part of the transaction batch. If this proof is valid, the rollup reworks its blockchain to delete this batch.

After 7 days with no fraud proofs, the batch is automatically considered valid, and all messages and withdrawals are finalized on Ethereum. You probably already figured it out, due to a 7-day delay in messaging Tal1, sending cross-chain transactions from an optimistic roll-up is a terrible idea. Why? Well, will you wait for your deck swap for a week? What's going to happen with the price by this time? Sending cross-chain transactions to the optimistic rollup is much better. Eventhaw the op stack sequencer waits a few blocks before processing the message to minimize the possibility of reorgs, waiting a few minutes for your transaction is already somewhat acceptable for some tasks. Moreover, the Ethereum community is currently working on single-slot finality,

which will make every block finalize separately, making them irreversible by their next block. After it's implemented, messaging from L1 to L2 will take about 12 seconds. Hosting such accounts on ZK rollups would be better, but still not very usable. As we can see from the stats below, ZK sync error finalizes in 21 hours, Linea in 5 hours, Starknet in 9 hours, etc. But why is it like this? Isn't ZK proof generation fast on powerful clusters? In short, there are two problems. Some ZK rollups, such as ZK-SYNC-ERA, set execution delays so that the Security Council has time to revert some batches in case of a bug in their proof system. ZK EVMs are really complicated pieces

of technology, and due to this complexity, probabilistically preventing bugs by using multiple proof systems at once is not yet feasible. Even though ZK proof verification is very light compared to the computations it proves, verifying it on-chain is still pretty expensive. Depending on the proof system, it can take up to a million gas per verification. Taking the average gas price of 9 GWEI and today's ETH prices, a single proof costs about $30 only for verification on L1. Modern ZK rollups minimize these expenses by generating one proof for many batches once per a certain amount of time, but this slows bridge finality speed. Generating a batch and proving it every block makes $30 per block or $216,000 per day. At 100 TPS, this is about $0.025 per

transaction just for verification costs. And we've also got to generate the proof and publish the batch on-chain. Waiting an hour or two for a transaction is still too long. What can we do about it? First of all, let's forget my 8-month-old hackathon project and try to eliminate the mental model that every transaction needs to be initiated from our main smart wallet. Why do we even need to share our smart wallet logic in every roll-up? Why don't we just generate temporary EOAs, bridge the funds from our main smart wallet there, do some work we want to do, and bridge what's left back? My Clave, or whatever smart wallet you're using, has secure enclave signing and social recovery, so I can always be safe about my funds there, even if I lose my phone. And who cares what happens with those temporary accounts? I've already done my stuff with them, all funds are on my Clave now.

However, this approach has a fundamental problem. The assumption that you can't use the same wallet on other chains on a regular basis heavily restricts the number of tasks you can do on them. For example, you can't create a deposit in a local lending platform because you can't migrate it to your main network zk-sync era in this case. Get tokens that don't have a fungible equivalent in your main network, zkSync era in this case. Get tokens that don't have a fungible equivalent in your main network, e.g. If they're natively minted on that network, participate in a local DAO because your votes have to stay in that temporary account. Essentially, all you can do as a user is disperse funds to multiple recipients without bridging each time and get better liquidity

for a swap to a token that can be bridged back to your main chain. Thus, to make these wallets useful, we have to access them using the same rulesway used on our main smart wallets, secure enclaves, social recovery, etc. So, we get back to the idea above and its infeasibility. There is, however, a feasible palliative that can give these mini-accounts only recovery properties of our main wallet. We create the same mini-accounts described earlier but allow one key to send transactions from them directly. Our parent wallet can now change this key through the L1-based bridge or make the mini-account read it from the parent L2's state. This way, if the temporary key is lost, the parent wallet can initiate a key change through the slow but atomic L1-based bridge. Greater than atomicity. The property of an action that doesn't allow it

to fail during greater than execution. Either it wasn't initiated, or it was done. L1-based bridges are greater than atomic because the message can't be lost if it's sent. Ordering, availability, greater than and authenticity are guaranteed by the ethereum l1 this is much better now ordinary transactions only take time for token bridging after the tokens are at the destination sending transactions is as fast as if it's your main chain if you lose the key you'll have to wait from several hours to seven days depending on the chain of your parent wallet but you won't use it very often so the trade-off is acceptable for most use cases. Also, it's feasible to implement in wallets even today. I even made my own implementation, but it's not by any means secure or production-ready

and is meant only for visualization purposes. A similar technique is used in Web3 futures trading platforms. You approve the token in pair pair usually usdc to the smart contract and assign a temporary key for spending which is stored on the platform's front end this allows users to perform fast actions without signing each action with their main wallet if you change your device or clear the data in your browser you can just reassign the key using your main wallet but just as with everything in crypto, this approach is not perfect either. It has two disadvantages. Even though mini-accounts can be ERC-4337 compliant and thus support all its features, such as batching, paymasters,

spending limits, etc. These features are no longer inherited from the parent account. In fact, the parent account just acts as a single social recovery guardian for the mini account, but the guardian is the user themselves. Token bridging must be accomplished using external bridges. With cross-chain transaction initiation, we can carry our tokens with the message, receiving them practically one-to-one in an atomic way. However, with this solution, this is no longer an option, so external bridging is the only fast option left. Even though modern bridges can transfer funds in a few seconds, they take a fee that can get awfully high on large transfers,

b. are not atomic, and don't inherit Ethereum's security properties. It is particularly important to take note about security properties of blockchain bridges. Using external bridges to transfer tokens is somewhat acceptable, unlike using them to pass messages to operate mini-accounts. The reason is their worst cases, likely due to an attack on them in token bridging. The worst that can happen is that you won't receive the tokens you sent. In such case, you lose X tokens you wanted to bridge and switch to another bridge. In cross-account messaging, the worst that can happen is that all your mini-accounts can be

stolen by passing impersonating messages through the bridge. In such case, you lose your wallets on all chains with all their value, except your main one. As such, relying on external bridges for token bridging is pretty much an option as long as one has no efficient way to bridge them in an atomic way using L1. This is in fact the option used by many users interacting with rollup chains today. Suppose we want to validate all transactions in a single place, for example, tonatively transfer tokens between accounts or verify signatures with a unique precompile. In that case, we face the slow finality of today's ZK rollups. Let's return for a little while to think of what can be improved with the previous technique. Why do rollups have slow bridge finality? We'll take ZK rollups as a target

because, with optimistic ones, the reason is already apparent ZK proof systems for full-fledged VM environments are complicated, especially if the environment is not ZK-friendly, EVM. Therefore, there is a high chance that they will contain bugs. Multiple proof systems can prevent this, but such are very complicated to implement, and generating multiple proofs for a single batch may be too slow and expensive. As a workaround, rollup teams enable execution delays, which allow them to roll back the chain in an emergency. This is what slows the bridge finality in some rollups, e.g. ZK Sync Era, proposing the new state and ZK proving it to L1 are pretty expensive tasks, so to minimize costs, the rollup sequencers do it every few hours rather than every block. There is an exception, however, scroll proposes the state about every minute, but ache-proof verifying is still done every few hours, so it stays unverified, and b. Scroll is one of the most expensive rollups to use today.

If we rephrase it even more simply, the problems are proving costs and verifying costs. Let's look at each problem and ways to solve it. Essentially, our task is to make our smart wallet on a rollup quickly interoperate with other rollups without additional trust assumptions brought by external bridges. Smart wallets typically consist of a few usual awe features, paymasters, social recovery, secure enclaves, spending limits, etc. And the main operation that allows us to send on-chain transactions from it. Why do we need the main operation if we want to use the other rollups from our wallet? Because it is probably hosted on a multi-purpose rollup, Arbitrum, Base, ZK-Sync era, and we want to interact with users and smart contracts on this rollup, too. In this particular case,

it would make sense to simply use external token bridges. Just replace the task with, for example, interaction with a dApp in the same rollup and another one. This multipurposeness is what introduces complexity to the proof system of the rollups. Verifying the state of the entire virtual machine with lots of smart contracts and transactions happening every second is a pretty tall order. We want to execute two types of tasks that require a completely different set of features in the rollup. For an on-chain transaction, it is fast L2 inclusion, low L2 fees, and wide functionality of VM, and for a multi-rollup transaction, it's fast bridge finality. But what if we just get rid of the virtual machine and build a rollup that can only handle smart accounts and messaging to the other L2s? Vitalik Buterin proposed a similar technique at

just about the time of DevConnect Istanbul called, Keystore Rollups. We discuss this next. Keystore Rollups. The idea is to create a ZK rollup that can only store the account keys and change them using another key. This rollup pushes the root of the Merkle tree that contains all these keys to L1. Then, when you want to send a transaction from one of your smart accounts on L2s, you generate the Merkle proof of your current key, and your account verifies it against the keystore root available on the L1. Now, it knows your key and can use it to verify your signatures. Such a rollup is very simple, and multiple proof systems can easily be implemented, so keys stored in it are actually as secure as the L1.

Besides Vitalik's original design, there are three leading ones for key store rollups. Scroll's approach is to store key store data on L1 but allow updating it from their ZK-EVM rollup. For this, they're introducing an L1 SLOAD precompile that allows for cheap reads of L1 storage. Then, AHA accounts on other L2s can read this data to synchronize their configuration, keys, guardians, etc. Base team is exploring a technique where only the state root is stored on L1, but transactions are sequenced using call data, so the tree can always be rebuilt. Accounts on L2s are expected to fetch current keys using Merkle proofs. Stacker's design is very similar to Basie's or Vitalik's, but it utilizes its own framework of

micro-rollups with specialized minimal VMs. Generally speaking, they differ in the number of tasks delegated to off-chain processing, in other words, how many things are on L2 and their implementation details. We can expand this idea further by handling not only the keys but also the entire smart account logic. This wouldn't be much more computationally difficult, either. Essentially, we only need to handle these tasks sending data to L1. Accounts on the keystore rollup must be able to notify L1 about their transaction intent. Storing the entire transaction on L1 is not necessary. Something like a root of a Merkle tree with all hashes of the user operations would be enough. However, this might be a relatively safe option as long as the rollup doesn't get too large.

When it does, the transaction demand could already make L1 Pro a verification worthwhile. According to Docs, verifying the ZK proof using Align costs about 3,000 gas, which is nearly free even for Ethereum L1. Proof aggregation layers. If you're uncomfortable introducing additional trust assumptions to the system, or your protocol has already become too large, but its transaction demand has not, there's an alternative. ZK and roll-up teams have recently started actively working on proof aggregation protocols. If you're not very familiar with ZK, proof aggregation is when a ZK proof proves the validity of another ZK proof. That can, in turn, prove another proof, and so on, thus aggregating them in the single proof and

essentially moving all their verifying costs to proving costs. What's left is verifying a single ZK proof on-chain and being sure about the validity of all the other ZK proofs it proves. Few ZK proof on-chain verification. Proof aggregation makes sense where verifying costs are higher than proving aggregating proofs. That is, aggregation becomes profitable if the cost of generating a proof for 10 proofs and verifying it is less than verifying the set and proofs independently. This is even more helpful in Ethereum L1, which is heavily restricted by computational capacity. Depending on the proof system, the entire block can only contain about 100 proof verifications, excluding all the other on-chain activities. Generally, there are two

types of proof aggregation protocols. General purpose, universal, aggregation. Such projects usually support several of the most popular ZK protocols, Groth-16, Halo-2, Plonky, on top of which most ZK circuits are built and take a fee for processing. The DAPPs that need the proofs then reveal the data from the protocol and process it on their own. Nebra's universal proof aggregation system, currently in development, does exactly this. Aligned is also working on so-called slow mode verification, which is, in fact, a proof aggregation system too. Aggregating shared rollup bridges. Similarly to shared sequencing in optimistic rollups, ZK rollups with their stacks are working on shared bridges with aggregated state proofs

for every ZK rollup in the bridge. This not only allows synchronous composability inside the stack shared sequencing but also minimizes the costs for proof verification. You might have heard of Polygon's ag layer or zkSync's hyperbridge, which are shared roll-up bridges that work on proof aggregation inside the bridge. The advantages of universal aggregation systems are that they are project agnostic and only specialize in the aggregation process itself, which opens pretty fast verification of proofs and low costs. Also, it's likely not to hobby training wheels because of the lack of the bridge component. Aggregated roll-up bridges, in turn, are helpful for the keystore roll-up to have

synchronous composability with an already existing roll-up stack. For example, according to L2BEAT, 13 projects are currently built using Polygon CDK and 11 use ZKStack. When they all connect to a shared proof aggregating bridge, connecting the keystore rollup to one of them will open seamless interaction with many L2s without even touching the L1. For this to work, the bridge must support different state transition logic for its L2s because the keystore rollup's logic differs from the other L2s in it. However, these bridges are usually upgradable and controlled by its DAO or Security Council. Keystore rollup projects may not be comfortable with giving up their sovereignty to the operators of the bridge they're connected to. Also, bridges may introduce execution delays

as a training wheel's precaution, similar to how zkSync era operates now, which essentially kills the entire efficiency of this keystore rollup design. This way, keystore rollups, like any other zk rollups, can minimize proa verification costs and even combine this with synchronous composability with an already existing rollup stack. Efficient intent-based bridging with keystore plus rollups. As previously discussed, bridging from L2 to L1 is not the only problem. Most rollup sequencers also apply delays to passing messages from L1 to L2. This is because when an Ethereum block is created, it's not yet final and can perverse within the following approximately 64 blocks, 2 epochs, about 13 minutes.

These errors happen because of network latencies, following approximately 64 blocks, 2 epochs, about 13 minutes. These reorgs happen because of network latencies, causing some proposals to appear in the network too late when some nodes already consider them missed. Even though most reorgs are no deeper than 2 blocks, a 7-block reorg even appeared in the news two years ago, rollup teams still don't want to take risks related to missed messages and apply delays to bridging from L1. These delays are a just about one minute on some rollups, op stack, zk stack, but can be up to 6 minutes, as in Arbitrum, or even ask for L1 finality, as in Linea. Ethereum community is actively working on single-slot finality, which will make each block finalize independently

instead of once in an epoch. But we can say for sure that it isn't planned for the next Pectra upgrade coming in Q1 2025, SWA will be at least a year before SSF gets implemented. If a team implementing this extended keystore roll-up design isn't comfortable with such transaction latency, it can implement a palliative described earlier. Every mini-account has a key authorized to send transactions or utilizes a static key from the keystore, as per Vitalik's original design, but account management is still on the main keystore account. After SSF is implemented on L1, the rollup can remove the authorized spending keys, and users will get the entire AA customization functionality without

significant speed degradation. I agree with Alex here, 15 seconds of latency is absolutely acceptable, especially since the operation is atomic after the keystore rollup transaction is finalized on L1. If we talk about token transfers, recipient wallets can even implement a pending status on the UI level. However, cross-rollup token transfers still present a problem. If we implement token vaults inside the key level. However, cross-rollup token transfers still present a problem. If we implement token vaults inside the keystore rollup, transferring tokens from it will take 1 to 15 minutes, depending on the recipient rollup. If we do not, splitting users' balances into mini accounts on multiple L2s can pose security risks and even lock some assets into illiquid L2s,

bridging from which may cost too much or take too long. As an alternative, we can integrate an intent-based bridge into the rollup and deploy it on all the other rollups or even reuse existing infrastructure, such as ERC 7683 compliant protocols. We'll briefly discuss intent bridges in the next section. What is an intent-based bridge? Most existing cross-chain bridges are based on messaging protocols. For example, Stargate uses Layer 0 to pass messages about deposits to destination chains, relying on it as the source of trust. When you send tokens through such bridges, they lock your tokens on one side and send a message about your deposit on the other side, and the vault there unlocks the respective amount of tokens for you. Intent-based bridges, in turn, do not send messages between two chains. Instead,

funds being sent are locked in the vault as a cross-chain order, and the nanny one can fill the order by sending the requested amount of tokens on the destination chain. Whoever fills the order can then claim the locked tokens from the source chain when the vault in it gets informed about the finalized state of the destination chain and can confirm the transfer. This can happen either by waiting for the destination chain's objective, bridge, finality or via some external oracle protocol. For example, Acros uses UMA's optimistic oracle to fetch the state of not yet finalized L2s. In this scenario, Ethereum L1 is used as the source of

trust. Some protocols, such as Across, use external oracles instead. The actual design may differ in existing projects, only the general idea is displayed. We can use the same design for these extended keystore rollups to implement trustless, fast, and cheap two-way bridging between the keystore and all other L2s. Fast bridge finality allows intent-based orders from the other L2s to be nearly free because proving the fulfillment on the L2 takes just a few minutes. Orders from the keystore will probably be cheap as well, as liquidity on the L2 can be supplied relatively fast through the keystore. This way, such keystore role-up design can become a hub for

intent-based bridging, allowing users to send transactions instantly rather than in a few minutes, paying nearly nothing for bridging. The roll-up team can also supply liquidity for bridging through the keystore one-to-one, and this would not cost them a lot. Unified ENS name for all chains. Imagine having a single username, ETH that resolves to all your mini accounts, no matter which chain the recipient is on. This design makes this possible. How? As we already know the address of our main keystore account, we can use multi-chain factories and create two to make the addresses of our mini accounts the same across all bytecode equivalent EVM chains, even including Ethereum L1. Then, we set the unified address in the ENS resolver, and our name works in all EVM L2s. However, there are two exceptional

cases, bytecode in equivalent EVMs, such as ZKStack. For them, we can generate a custom address according to their create2 rules and add it to the ENS with their chain identifiers according to ENS IP 11. Non-EVML2s, such as our keystore, the logic is the same for them, but instead, we add their custom addresses to the ENS according to ENS IP 9. While being very UX-friendly, this approach uses a lot of expensive computation and storage on L1 because names and addresses are stored on L1 resolvers. This problem can be solved using CCIP read, but I came up with another, more efficient on-chain resolution logic. Every account on the keystore is registered and indexed by the name hash of its ENS name, registered under a single ENS name with a custom resolver. When its subdomain is resolved, the resolver contract checks if the

account with such name hash exists in the rollup and uses the name hash to generate based mini account addresses. When these are deployed, they will ask L1 for the keystore data belonging to the name hash they were deployed with. It can be the transaction intent itself or just the current signing key, depending on keystore implementation. This way, we get Keystore accounts, each with an ENS name resolving to itself and its mini accounts on each rollup. These mini accounts, in turn, will also rely on this ENS name when validating the transaction using the Keystore rollup. N** sequencing mechanisms on Keystore plus ROLLUPSA's bridge finality on the extended Keystore rollup is supposed to be a few L1 blocks, we may as well get rid of the centralized sequencers entirely,

turning it into a based rollup. As we've discussed before, approximately 12 seconds of transaction speed is acceptable for the average user, but based sequencing would make the rollup much more resistant to censorship and single points of failure. It's worth considering that with based sequencing, internal transactions will take as long as external ones, excluding time to reach L2. This may be unacceptable for some teams, as centralized sequencing makes all internal operations instant. Alternative Roll-Up Interoperability Solutions OR. Why I did not mention S-H-A-R-E-D-S-E-Q-U-E-N-C-I-N-G-I wrote the entire article around ZK roll-ups and ZK technology. This is because optimistic roll-ups cannot fundamentally have fast objective finality, and such a property is only reachable

using ZK. Today's optimistic roll-ups understand their sealed position and are actively researching the feasibility of integrating validity-centric designs in their stacks. Hence, for example, the recent partnership of Optimism and Risk Zero. Optimistic design is fundamentally restrictive in that it will never handle interoperability with other roll-ups. However, interoperability within the optimistic ecosystem is developing rapidly. The primary technology for making optimistic rollups interoperable with each other is shared sequencing. Simply put, this is a mechanism where a sequencer can build a batch for multiple rollups simultaneously. If any transaction in any of the rollups sequenced is invalid, the entire batch can be disputed and reverted. This gives all batches in this mega batch the atomic property.

Either all batches are valid or none. This, in turn, allows for atomic synchronous composability inside the batch. Atomic, because nothing in the batch can be invalid if it is valid. Synchronous, because all messaging is inside the batch, which is processed simultaneously by all its rollups nodes. This technology basically turns all rollups in a certain optimistic stack into an big, sharded rollup. Why only one stack and not all of them? Because in order for this to work, rollups must be connected to a single bridge. Each stack has its own bridge, and there's no reliable way to build batches in multiple bridges simultaneously. This means that shared

sequencing allows OpMainnet to seamlessly interoperate with Base and Zora but not Arbitrum or Métis, and vice versa. Such consolidation creates a dangerous situation in the roll-up ecosystem. New roll-ups have the option to either join the existing stack and be integrated with it but not with anyone else or build on top of ZK and be integrated with anyone but the stack above. There is no such choice now because shared sequencing is not yet available, and each op stack or arbitrum orbit rollup is independent, with its own bridge. However, when they consolidate, they will form two solid organisms within the ecosystem, each holding about 40% of total L2's TVL. Okay, if they will hold the vast majority of total TVL, why don't we get rid OFZK and build on top of them instead?

First of all, shared sequencers are a huge centralization driver. If you run a NOP mainnet sequencer, your batches won't include transactions from other rollups in the stack. You'll earn less in fees and eventually be outshined by large commercial sequencers that can handle the entire stack in their batches. However, the most critical problem is that in such a case, the roll-up ecosystem becomes enclosed within oligopolistic empires pursuing their own interests, seeking to establish more control over the capital, and slacking on technological progress in the ecosystem. We would then have to deal with Ethereum being crushed into a disjunct area where PR and intraspecific struggle are a what matter, not technologies that actually change the world. Greater than, build tools, not empires.

Empires try to capture and trap the user inside a greater than walled garden. Tools do their task but otherwise interoperate with a wider greater than open ecosystem. Vitalik Buterin, How are aggregating shared bridges in ZK better than optimistic SHAREDSEQUENCING? In ZK rollups shared bridges, sequencing can be done independently from the other rollups in the bridge. Each rollup can have its own sequencer or implement shared sequencing. Proposers who assert the resulting state root after all sequenced batches and prove it using ZK are the ones doing aggregation. Moreover, the characteristic of relatively fast objective finality in ZK rollups does not make them enclosed inside their ecosystem, no matter how large it grows or how centralized it is. No matter how large it grows, the ecosystem should not feel like a dozen distinct empires

boot as one large mechanism. So different, but so identical. We are not early, and this article is supposed to show you that. We must use all our strengths to develop working systems that help the gigantic L2 ecosystem interoperate. This is possible right now. Soon, you should be able to participate in any DAO and send any assets to the ENS, the owner of which is several thousand kilometers from you. Geographical borders should not be replaced by digital ones. If you liked this work, agree with its thesis, learn something new, or want to spread this message further, share it on social media, leave your comments, and talk about the importance of roll-up

interoperability more. Thank you for reading. Author's note. A version of this article was previously published here. Thank you for listening to this HackerNoon story, read by Artificial Intelligence. Visit HackerNoon.com to read, write, learn and publish.