Joel at Placeholder VC recently published an article defining rollups as virtual blockchains. In this article, we’ll propose a mental model for rollup or virtual chain design to help guide future experimentation.
Various innovations like the Application BlockChain Interface (ABCI) in Cosmos opens up the design space for virtual chains. The modular blockchain movement also significantly changes the way virtual chains are designed but we will cover that in a future article. For this first article, we’ll focus first on high level virtual chain design.
The design space of virtual blockchains is the next great frontier. The next generation of protocols will be created and existing protocols will evolve. Polymer is exploring this design space with our approach to integrating IBC which we’ll dive into at the end of this blog. Let’s take a look at where we started and explore where we could be headed.
A Primer
Before discussing virtual chain design specifically, let’s review blockchain design at a very high level. Let’s use application to refer to the part of the blockchain that defines the state transition function and server to refer to the part that deals with consensus.
Using the ABCI as an example, we can see that the Cosmos SDK can play the part of the application while CometBFT can play the part of a server. The application and server are separated by the ABCI in this case.
This concept can be generalized to Ethereum as well where the beacon node plays the part of the server and the execution engine plays the part of the application. The application and server are separated by the Engine API in this case.
Now that we’ve introduced the logical separation of a blockchain into application and server, let’s map this logical model to virtual chain design.
Single Application Single Server
Currently, most virtual chains can be modeled as a single application and a single server. In Celestia’s sovereign rollup framework, Rollkit plays the role of the server while an arbitrary ABCI application plays the part of the application. While the application continues to define the state transition function, the server no longer provides consensus but rather settlement logic.
Rollup frameworks on Ethereum generally follow this model as well. In the OP stack, op-node plays the role of the server while op-geth plays the role of the application.
A virtual chain doesn’t need to be limited to having a single application. Let’s use a web2 analogy to motivate this idea.
A Web2 Analogy
The cloud native movement in web2 has placed containerization and OSS such as docker at the top of an engineer’s toolbox. In the diagram below, individual docker containers serve as the application layer while the docker daemon serves as the server layer.
A single docker daemon can manage multiple docker containers. This rather simple idea is true for virtual chains as well. A single virtual chain server can manage multiple virtual chain applications.
Multi Application Single Server
This is where the design space starts to get interesting. Instead of having a single ABCI application. A virtual chain server can service multiple applications simultaneously that provide different functions.
In the example below, each application provides either a different VM or interoperability capabilities such as IBC. We’ll explore how this design pattern works well with IBC later in this article.
At this point, you’re probably wondering why we should stop at multiple applications. Why not introduce multiple servers as well?
Multi Application Multi Server
The multi server model makes virtual chain design even more interesting. In the diagram below, we have an example with two ABCI servers. Having CometBFT here may seem pointless as virtual chains do not require consensus but here’s where unexplored design space lies. CometBFT can be used in conjunction with Rollkit to provide a decentralized sequencer. Throw in Skip’s Block SDK into the mix and now the application is able to inform the sequencer’s transaction ordering strategy.
Next let’s dig a little deeper using the IBC ABCI application example from earlier in the article.
An IBC Example
In a previous article we covered the concept of enshrined interoperability which has numerous advantages in creating a scalable interoperability network. With the multi application model below, we can provide interoperability to a virtual chain by providing a docker container or a self contained IBC ABCI application that connects applications locally to each as well as to remote chains as well.
We can see in the example below that two VM applications are connected using a localhost or loopback IBC connection. The IBC application also maintains connections with both Osmosis and the Cosmos Hub as well. Applications may now communicate either locally or remotely in the same fashion over IBC. This means that the various VM applications do not need to implement interoperability functionality.
This design really sinks in when we replace all of the web3 things with the web2 analogy we used earlier. In the following diagram, localhost TCP/IP connections are created between docker containers with one docker container maintaining remote TCP/IP connections. This docker container connected to the outside world can be considered a networking sidecar proxy that helps create a service mesh to manage network traffic and connections. This design pattern has become increasingly popular in cloud computing.
Where Polymer Fits In
Let’s go back to the concept of a service mesh here using Istio as an example here. Istio’s service mesh consists of a data and a control plane. An Envoy proxy is deployed alongside each service to intercept all traffic forming the data plane as a networking sidecar. The data plane alone cannot make routing decisions as it is not network topology or routing configuration aware. The control plane dynamically programs the Envoy proxies with routing configurations and injects its view of the broader network topology allowing for service discovery.
Using the Istio analogy above, Polymer forms the control plane of the IBC service mesh. An IBC proxy contract or module is deployed to each virtual chain which proxies IBC related requests to Polymer. The IBC proxy is a pass-through construct with most of the actual IBC logic and functionality existing on Polymer. These IBC proxy contracts can be permissionlessly deployed and connected to Polymer allowing for permissionless expansion of the IBC network.
Let’s expand this further by modifying the IBC example we went over earlier and replacing the IBC ABCI application with Polymer instead. Polymer can exist outside of the virtual chain while still providing the same connectivity that the local IBC ABCI application was doing previously. Below, we visualize Polymer connecting two virtual chains using local IBC connections while maintaining two remote IBC connections.
Let’s continue with the Polymer IBC example but visualize it within the context of Ethereum and its rollups. In an abstract sense, each rollup on Ethereum plays the role of an application over the Engine API interface. Polymer also plays the role of an application which specializes in providing IBC connectivity to other rollups or applications on Ethereum.
Going back to the Istio analogy, Polymer acts as the control plane of the IBC network creating a service mesh over connected virtual chains. It lays the foundation for the decentralized web to operate over open, neutral and permissionless interoperability rails. For any developers interested in participating in the Polymer testnet, we have an early testnet sign up at the bottom of this blog.
About Polymer Labs
Polymer Labs, composed of skilled distributed systems and infrastructure engineers, crypto pioneers, and accomplished business operators, is at the forefront of advancing Ethereum interoperability with IBC. With technical values based on TCP/IP, Polymer’s mission is to establish the next generation of the internet by ensuring that the interoperability layer of the decentralized web is neutral, open, permissionless, and uniform across ecosystems. As the creators of the Ethereum Interoperability Hub, the first Layer 2 focused on enabling IBC interoperability, Polymer sets a new standard in blockchain technology.
Polymer is a contributor to Inter-Blockchain Communication (an OSS standard for arbitrary message passing) and an active steward of the IBC community, including spearheading IBC Summit and OpenIBC. We invite value aligned builders, investors and the broader community to join us in our mission to scale the decentralized web.
Follow us on X and sign up for our newsletter on our website to learn more. If you would like to join us in building an interoperable future for crypto, check out our careers page.
