Understanding Rome Protocol - A Deep Dive
Ethereum for settlement, Solana for sequencing, and Celestia for Data availability. What is Rome protocol?
The user experience of blockchains had been somewhat finalized that it can never be improved due to three factors that cannot be mutually exclusive — the blockchain trilemma.
Every blockchain network tries as much as possible to ensure decentralization, scalability, and security. This maintains the state of why a network is created, can achieve high or low throughput and gas fees during transactions, and builds a consensus that protects the network from a coordinated attack. In as much as these three (3) factors have been kept in hindsight, it remains highly impossible for a single blockchain to satisfy all of them hence the reason for mutual exclusivity.
Ethereum for example, before the Dencun upgrade, had throughput issues, hence leading to high gas fees and bringing about delays when processing transactions before reaching finality. In as much as the scalability wasn’t satisfactory for its users, its level of decentralization and security was highly functional, this imposes the illusion that one of the factors must serve as an opportunity cost for the other two.
As an evolving space, to improve on any of the issues such as scalability, different solutions has been introduced such as rollups, validiums, and customized appchains. Despite these different solutions provided, there are layers built into their individual architectures on how transactions are recorded, stored, and carried out. These solutions are alt-L1s but irrespective of the solution itself, common parts of their architecture exist.
Every part of a solution’s architecture has:
Execution Layer
Settlement Layer
Consensus layer and;
Data availability layer.
Some blockchains execute, settle transactions, achieve consensus, and stores the state of data in real-time and apparently at the same time while some blockchains may perform the following actions mentioned asynchronously. Blockchains can either be classified into monolithics, modular, and semi-monolithics.
Using a mental visualization of a highway;
On a typical highway, trucks, cars, motorcycles, cabs and even trailers makes use of it for transportation. On some occasions, a delay of transportation might take place as these different vehicles are likely to cause holdup, create potholes, and even bring about accidents.
Apparently, this is how transactions are processed on monolithic blockchains, but for modular blockchains, transactions aren’t processed at the same level, a different route can be designed specifically for trucks, another just for cabs, and another just for motorcycles. With this new design, reaching the destination can be much faster — in blockchain this is regarded as finality.
Rome protocol being a modular protocol will draw this article around the axis of its modularity, how it is designed and other concepts surrounding it.
What is modularity?
This concept was initially introduced by Mustafa Al-Bassam in this research paper where he proposed LazyLedger as a blockchain solely designed for the offloading of transactions and guaranteeing the proper storage of the data of these transactions.
Reflecting back to the architectures I listed earlier down to the mental visualization which I tried to present, major blockchains such as Bitcoin and Ethereum existed as monolithic blockchains where execution of transactions, verifying and agreeing if a transaction is valid alongside how these recorded state of data is stored and where its security is based on was all carried on the same layer — you can link this to the highway model.
This created friction to user experience and new ways were introduced birthing modularity which introduced sharding, subnets, and parachains as a means to safe cost, achieve high throughput and process transactions faster.
Modularity introduces specialization through the offloading of specific actions from the base layer down to another layer to execute a core function (it could be data availability) then these data can be sent and recorded across. You can as well term it as being able to spilt the task that would have been done on one layer.
A single layer carrying out the transactions of the network, especially in data availability computation. In data availability computation, the state of data would be required to be kept across all nodes for maximum security to enable all nodes to have a constant and non-variant state, but gradual and frequent processing of transactions would require full nodes to keep up with the sequencer’s rate of transaction computation, thereby raising the hardware requirements and consequently worsening the network’s decentralization (as barriers of entry to participate in block production/verification increase).
Modularity isn’t restricted to only data availability purposes, Rome Protocol presents a different approach to modularity.
Introduction to Rome Protocol
In the concept of blockchain, data availability complements the capacity of a network to be able to process transactions. While preserving the state of data across nodes, it isn’t fixed that an off-chain layer or alternative data availability layer has to be created to store the state of data. Hence scalability can not only be enhanced by modular chains. The scalability of a blockchain depends on how it runs which can either be vertically scaled or horizontally.
A modular or monolithic chain can decide to process transactions and store the state of data either vertically or horizontally. However if a rollup is being built, it can be designed specifically for a particular ecosystem. Most especially Ethereum.
To achieve modularity on a higher level, Rome protocol presents itself as a rollup to achieve modularization and composability by using Solana as a sequencing layer. To achieve this state, Rome protocol introduces its tech stack for L2s on Ethereum through:
Rome EVM
Rome Shared Sequencer.
Rome Interop and;
Rome Data Availability(Rome DA).
Why Solana?
It’s typical for any question concerning why Solana needs to be modularized. Rome protocol does not particularly modularize Solana in any way but to leverage its tech stack. Solana’s speed and infrastructure are hinged on these three factors: its hardware factors, time architecture, and composability. These three (3) factors keep it ahead of other layer-1 blockchains making it faster and a better layer to help L2s achieve a state of high finality.
Regarding these three factors, on the hardware level, Solana leverages and relies on hardware advancements to hedge against the challenges of protocol advancement at the software level, guaranteeing that its speed and ability to scale will increase as hardware improves. This clearly shows that its hardware architecture is built on monolithic processing capabilities.
Rome modularizing Solana’s consensus is leveraging the second factor — time architecture. Solana decouples time from state updates in real-time, giving room for synchronicity. In contrast with other chains, which process transactions in batches, this one-factor composability ensures high interoperability. Reflecting on the tech stack of Rome protocol, the Rome EVM is one important point of interest.
Rome EVM
The Rome Ethereum Virtual Machine is responsible for allowing users to do EVM transactions on Solana and as well deploy EVM-based Dapps to be with SPL and ERC-20 token interoperability.
The SPL (Solana Program Library) is specifically designed for tokens that operate on Solana’s virtual machine, while ERC-20 tokens are built for the Ethereum Virtual Machine (EVM) and follow Ethereum’s standards. This is bridged despite the two token types existing in two different ecosystems.
The disparity in token compatibility lies in the runtime environment, where Solana is built with LLVM — a low-level virtual machine that deals mostly with assembly language and is majorly compatible with its design built for hardware optimization.
Due to these differences, Rome protocol designs its EVM to run with the following:
An Ethereum Client — OP GETH
Rhea — a roll-up smart contract on Solana and;
Hercules.
A typical virtual machine, to keep things simple — An EVM works as a virtual machine built into software that gives the computer functionality. This software is technically referred to as a client. In the world of virtual computers just like that of Ethereum, various clients exist; hence, Rome protocol leverages GETH.
Through the Ethereum client — OP GETH, users are able to use Ethereum RPCs to communicate the state transitions of the blockchain when transactions have been made successfully or not. In such cases, when a transaction is set to be processed by a user, a certain type of RPC communicates the state to the applications. Typically validators are the only actors that run the Ethereum virtual machine and pay attention to the state changes and transitions, communication of data and state is a combination of the work of the memory pool, JSON-RPC API, and the client process.
A standard JSON-RPC API has a structure in which data is structured and presented which is then processed and written to Ethereum but stored across all the nodes but not all nodes provide a means by which these data or state changes can be read. Data is only provided by RPC nodes to applications as they support the RPC protocol of which the applications and transactions on the Rome protocol is made possible.
As the end goal of Solana is to make use of Solana as the finality layer for how the transactions are stored alongside its speed, Rhea a roll-up smart contract on Solana remains another point of interest.
Enter Rhea and Hercules
A usual roll-up processes a transaction bundles it up, and sends it to the base layer for execution. But in a “usual rollup” there’s a compatibility between the rollup and the base layer say any OP rollup and Ethereum but for the tech that Rome introduces, Solana is regarded as the global state machine for the processes of the transactions through its uniqueness as explained previously.
Three processes are carried out before the final settlement is done on Ethereum:
Processing compatibility of Ethereum transactions.
Batching and bundling of Ethereum transactions.
Processing of the compatibility of Ethereum transactions can be reflected back to the initial start of the article where I mentioned the differences in the runtime environment for both ecosystems. First things, when a transaction is initiated, Rhea being a roll-up smart contract bundles up a single Ethereum transaction into Solana for execution and ordering or as well bundles up multiple Ethereum transactions into one which takes a similar process for execution and ordering of blocks.
When a transaction is bundled, Solana’s readability of the transaction is enhanced and passed on to Hercules. After readability and bundling, imagine bundling a group of sticks, sending it inside a disposable bag till it arrives at its final destination for confirmation.
In analogy, the sticks are the transactions, but at the final destination in our analogy, two things takes place before execution of transaction which is regarded as ordering of blocks. In most cases, front-running of transactions is possible and this is as a result of two transactions getting sandwiched but before it can be sandwiched, there must be an order to which the blocks are arranged. This is regarded as the ordering of blocks.
Ordering of these blocks is done by Solana which is then sent to Hercules for execution of the block’s payload. This payload which contains the state changes of transactions, gas fee spent and other arbitrary data. Due this process, there is an update and synchronicity activated on the rollup which ensures that its state is updated and the data remains the same at all points at which the transaction has passed.
Processing, execution, and ordering of blocks isn’t complete as in every blockchain transaction, execution, settlement, consensus, and data availability state must be maintained. To complete one of the two yet-to-be-mentioned is “settlement”. Settlement is not the deterministic finalization of a transaction. It is where the immutability of transaction is attained hence giving blockchains regarded as a static digital ledger.
Settlement on Rome is processed on the Ethereum network where finality is made this process takes from Hercules down to OP GETH client which in return shows on the EVM that a certain type of transaction on a certain day took place.
Aside the common question that may arise due to the reason because everyone thinks that the Solana and Ethereum ecosystem is competing with each other but in some true sense just for the maxis who are trying to push their bag but in terms of positive sum games, Solana serves to be the best execution environment (which Rome leverage through Hercules) and Ethereum as best for anyone to launch an execution environment such as Rollups and other scaling solution.
Solana and Ethereum as key chains makes it much easier to deal with the problem of interoperability and here’s where Rome Protocol shows how perfect the merging of these two different architectures alongside on their level of atomic composability.
On Rome Protocol’s Atomic Composability
Rome’s Architecture is structured due to the capabilities and structure of both Solana and Ethereum where the former handles execution and the latter finalization and validation of state changes. Despite the differences, both chains exist as monolithic chains with shortcomings such as:
Lack of control; customization, ordering, etc.
But monolithic chains construed to work as modular which is achieved by Rome helps in abstracting the shortcoming of the chains not being able to handle self customization and ordering hence this is now a problem solved by Rome.
Monolithic chains have superpowers despite their shortcomings which is most importantly their interoperability. Fragmentation of data and communication between layer-2s and customized roll-ups is limited and without being able to hold onto synchronicity and this is one of the core tenets to which Rome Protocol uses to reach for a high state of atomicity. In the context of this article, synchronous atomic composability will be the center of interest.
What is Atomicity?
Atomicity is a core tenet when it comes to the execution of a transaction to verify that a transaction processed succeeds all at once or fails as a bundle and not fragments of the transaction succeeding and the other failing.
Solana being a state machine achieves atomicity through Rome when transactions are initiated on Ethereum and readability has to be anchored by the Rollup, bundling and batching for the shared sequencer. But this doesn’t justify if Rome achieves atomic composability.
This process started remains a fraction of what atomic composability entails.
Atomic composability consists of two parts:
Atomic Execution and;
Atomic Commitment.
Atomic execution is regarded mainly as when transactions are processed, when execution is finally processed or not, or in the worst case if execution is successful altogether or not. Which Rome protocol achieves as stated about Ethereum initialization of transactions.
On the other hand is Atomic Commitment which is the finalization of transactions and locking of state changes across all nodes and other relevant network participant.
If both Atomic commitment and execution is achieved, then a product is said to reach atomic composability and that’s agreed for Rome Protocol.
Remember, after Hercules packages the block’s payload, it sends it down to Ethereum for settlement - this settlement is where atomic commitment takes place. During the execution and packaging; arbitrary data, gas fees, user account balance reflects, synchronize across all the nodes on Ethereum and transaction data can be stored permanently.
This makes Rome Protocol remain much more relevant and developer experience inclined because layer-2s and other scaling solutions despite being modular as Rome still face a problem of atomic commitments because shards and other components doesn’t synchronize and run in real time. For a layer-2 solution that using ZK fault proof, some verification has to be ensured before transactions is accepted asides problems such as time-outs, another problem depends on coordinating validators to agree on the validity of a transaction.
Due to this through Rome, certain verticals can attain a greater experience with low risk.
Relevant Verticals and Use Cases for Rome’s protocol’s tech:
Cross-chain development: Interoperability is a core tenet of why scaling solutions such as Layer-2 are created for scalability. However, there’s a limitation to the interaction one could get through DApps and chains. Likewise, the way when oracles were created to relay data and messages off-chain and on-chain. With Rome protocol, applications aren’t restricted to a single chain in terms of achieving throughput and low latency.
Infrastructure - RaaS: Rome protocol has its own tech stack, OP GETH, Rhea, Hercules, and its roll-up smart contract, developers can customize their applications to leverage Solana as a sequencing layer. This makes Rome protocol include a functionality present on all modular chains irrespective of how the processing is done.
Gaming: Gaming protocols face a problem of unification and interoperability. When it comes to unification, the data of users are stored across different servers, let’s say a user has to play an FPS (first-player shooter) game, after playing this game, the data stored across the server is fragmented, and processing of Web3 games is way too low hence bad UX.
Processing load can be reduced through Rome’s data availability storage format on Celestia and a protocol looking to get data of players or transactions can easily fetch it since everything is processed on a different layer contrary to how monolithic chains store and process their transactions.
Social Finance (Social-Fi): Most Social-Fi applications struggle to reach critical mass because of user experience, where a chain remains limited to how transactions are processed but leveraging the Rome stack can make these particular market able to bring on-chain activity to their applications.
Some social applications might want to introduce gaming into applications and some alt-1s aren’t the best option as they struggle with interoperability - lest not to struggle with this Solana makes it easier for the sequencing and Ethereum for settlement of transactions hence low latency and high throughput is achieved for anything that happens on-chain.
In Conclusion:
Modularity has been limited to only exist on Ethereum because Ethereum has always had a problem of scalability giving rise to alt-1s. Rome steps up this game by using Solana as a sequencer but so far given the verticals I just listed and the use case that follows it is natural and obvious to say that Rome protocol hasn’t been tapped and is quite an undervalued ecosystem for mother chains like Ethereum and Solana.
From gaming to DeFi, I believe there are wide opportunities for more innovations.
If you’re looking forward to deploying on Rome Protocol as a developer, refer to their docs here and join their discord here
References:
Now, that's what is called A DEEP DIVE.
Quite detailed and comprehensive with superb presentation! 👏🏽
Genius level understanding and superb presentation 😌. Well done bro☺️