At Initia, we’ve made rollups fast. Interwoven rollups (aka Minitias) are fast like Ferrari, 500ms block time fast. Now, would you rather take your mint-condition Ferrari out on a motorway with no speed limits — where you can drive it to its max — or on a cramped street where you end up pressing the brake more than the accelerator? 🏎️
But what’s the point of having a Ferrari if you’re stuck on a congested, pothole-ridden road? That’s exactly the problem we’re tackling in Initia’s Interwoven World. By the nature of a multi-chain ecosystem, these rollups need fast interoperability, it needs to feel slick. The whole premise of Initia’s app chain thesis is in shambles and all the good work we’ve done on making rollups fast is crying in a corner if the interop experience isn’t as fast and smooth as the rollups themselves.
To give an example, you gotta let the users cash out on their rent from owning properties on Civitia to using the profits to bet on who’s gonna win the superbowl on Contro within seconds. The multi-chain world just doesn’t work if interop isn’t fast.
And the importance is evident! Just in the 4 weeks of The Initiation Part 2: Initia’s Public Testnet there have been over 13.3 Million cross-chain messages to and from Minitias via IBC and the native OPinit Bridge.
To support Minitias’ elite performance and the millions of cross-chain messages they send, the good ole’ Hermes — the most widely used IBC relayer — just didn’t cut it.
What good is a high-performance sports car if the road you gotta drive it can’t get enough of potholes eh? That’s why we built the autobahn of IBC relayers: Rapid Relayer.
First, let’s get a little context.
Native Interop on Interwoven Rollups
Inter-Blockchain Communication (IBC) serves as the backbone of Omnitia, seamlessly interconnecting Initia L1 with Minitia L2s. It provides an end-to-end, reliable communication protocol that handles everything from token transfers to atomic swaps and cross-rollup contract calls, interweaving every Minitia together.
Imagine if The Omnitia had to rely on a jumble of different smart contract bridges. Not only would that create a maze of security risks and multiple versions of the same token, but it would also tie up huge amounts of liquidity — leading to a big, inefficient mess. Sounds like a world of pain. 💀
Fortunately, IBC steps in to untangle this mess by allowing users to rely on the trust they already have in their chains. When an IBC message is sent, it comes with a cryptographic proof that’s verified on the receiving chain through the source chain’s light client, minimizing trust assumptions in the process.
Even though the chains in Omnitia don’t all share the same VM, there is a common denominator — they’re all built with CosmosSDK under the hood. Initia’s seamless VM integration with CosmosSDK enables cross-chain comms across Move, CosmWasm, and Solidity smart contracts through IBC.
You know what that means? Minitia L2s enjoy fungibility between ICS20s, ERC20s, CW20s, MoveFAs, NFTs, and more across different VMs.
IBC — A Quick and Dirty Primer
So far, we know that IBC provides blockchains with a protocol to enable reliable, secure, and permissionless transfer data packets.
To minimize trust assumptions, each packet transfer is accompanied with a cryptographic proof, ensuring that the packet hasn’t been spoofed. This proof is then verified by the light client on the destination chain.
But how does the data packet get across the pond? This is where IBC Relayers come in.
Relayers serve as the physical connection layer between the chains by transferring the packets across networks. They monitor the chains they service for events that require an IBC packet to be sent. Then they package the packet along with the on-chain proof and submit it to the destination chain. Once the destination chain receives the packet, the relayer sends an acknowledgement message to the source chain.
What’s more, IBC relayers are permissionless to operate, meaning anyone can run one. This decentralization is key to avoiding single points of failure, ensuring the network remains robust and resilient.
And there you have it — the essentials of IBC. Now, let’s explore why we decided to build our own IBC relayer.
The Old Guard
Hermes (and sometimes the Go Relayer) is the go-to choice for 99.9% of CosmosSDK based chains, and for 9 out of 10 use-cases, it’s pretty kick-ass. It comes as a full-package solution for all things IBC ops.
But for us, cracks started to show in Hermes during The Initiation, it was stress-tested like never before. Millions of packets thrown at it, at a pace it hasn’t been designed to handle.
Hermes’ performance started to fall off when packets were thrown at it faster than it could handle, like trying to drive a high-performance sports car — Interwoven Rollup — through a narrow, congested street. Not exactly the motorway we were hoping for.
But why’s Hermes slow?
The biggest culprit for Hermes’ poor performance is how it searches for packets when it has missed some. It relies on tx_search a Cosmos RPC method-which is notoriously slow and cumbersome when it comes to locating and identifying the IBC messages that need to be delivered. Even though tx_search has gone under some work in the past, it still doesn’t cut it.
To make matters worse, tx_search is resource-intensive and burdensome for chain nodes, often leading to degraded RPC performance. This can have a cascading effect on the network, causing further delays and inefficiencies.
But, the root of the problem lies in why Hermes misses packets in the first place.
Hermes processes packets sequentially, block by block, moving on to Block N+1 only after it has fully processed all messages in Block N. While this approach might work under lighter loads, it becomes a significant bottleneck when block times are rapid and packets are generated in every block. This sequential processing can quickly lead to a backlog of missed packets, which then forces Hermes to rely on the slow and inefficient tx_search.
This approach is slow, painfully so. It’s clear that we needed something much faster — something truly rapid for when we need it.
Laying the foundation for the Autobahn
Rapid Relayer was built with one goal in mind: to handle the fast-paced demands of Initia’s interwoven rollups — to be the motorway these rollups deserve. It’s a lightweight IBC Relayer designed specifically to relay packets, rapidly and efficiently.
After identifying the specific bottlenecks in Hermes, we knew we needed a solution that could keep pace with our fast, interconnected rollups for when the workload is extreme. So, we went back to the drawing board and built Rapid Relayer to deliver the slickest, most efficient user experience in the blockchain world, ensuring that we can switch in Rapid Relayer to be the relayer of choice whenever packets start to pile up on Hermes.
We’ve already talked about what makes Hermes slow. Next step? We went back to the drawing board and built Rapid Relayer to be the complementary solution to Hermes.
Let’s take a peek behind the construction of the Autobahn (Rapid Relayer)
Multi-Threaded Workers
Rapid Relayer divides its responsibilities among three different workers that run in parallel:
- Latest Height Worker
- Event Feeder
- Packet Handler
For a relayer serving Chain A and Chain B, a set of these three workers is kicked-off to run continuously for both directions (i.e., two sets of workers) when the relayer is initialized. This structure ensures that no long-running process blocks another, allowing packets to be handled as they come in, regardless of whether they’re in the same block.
Latest Height Worker
This worker is crucial as it’s tasked with not only updating the latest block height and timestamp of the chain, but also ensuring that the Light Client for the chains are up-to-date as this is what’s used for proof verification.
Event Feeder
The Event Feeder fetches the results from up to 20 blocks, starting from the last-synced one, using block_results.
From the data of all the transactions, it extracts the packets to be sent and acknowledgments to be written from the events. Finally, it pushes all the packets into the packetsToHandle array, where they’ll be processed by the Packet Handler.
Packet Handler
On each execution, the Packet Handler slices off the first 50 packets in the queue waiting to be processed. It then categorizes these packets into three groups:
- Packets to be sent to the counterparty chain.
- Packets that have timed out.
- Acknowledgments for messages received from the counterparty.
The appropriate messages are generated for the packets and acknowledgments, which are then sent to the counterparty chain. For timeouts, the worker builds the messages, waits for 15 seconds, and then sends the messages to the chain.
Making Transaction Data Queries Faster
One of the standout improvements in Rapid Relayer is its efficient approach to handling missed packets. Instead of burdening the blockchain node with the bulky tx_search query, Rapid Relayer leverages the faster and lighter block_results method, dramatically reducing the strain on node resources and speeding up data retrieval.
(a jest)
Batch Processing Events Across Blocks
Another key performance improvement lies in how the Rapid Relayer’s Event Feeder Worker is designed.
Instead of handling events from a single block, it fetches and feeds packets from up to 20 blocks, as long as the number of packets in the queue is less than 1,000. This approach prevents the build-up of a large backlog of events yet to be indexed by the Relayer.
Phew, that covers the ground on what makes the Rapid Relayer special. We’ve peeled behind the construction of the Autobahn just a little, if you’re up for a deeper dive, I highly recommend skimming through the codebase.
Securing the Fast Lane
When you want to offer high-speed inter-blockchain communications, you need the right incentives for the ecosystem’s agents to keep things running smoothly. Think of it like paying a dedicated crew to maintain the Autobahn, ensuring it’s always in top condition for those high-speed drives.
That’s where the Restaked Relayer comes into play. It brings trustless incentives to IBC Relayer Operators by leveraging INIT tokens through MilkyWay, ensuring that operators have a financial stake in maintaining high performance and reliability.
By implementing strict performance thresholds in the AVS, the Restaked Relayer creates a system where operators are rewarded when they meet expectations and penalized (through slashing) when they fall short, leading to only reliable operators remaining in the set. This ensures that the operators are always aligned to perform at their best, keeping the network not only fast but also dependable.
The rewards on successful relay will also contribute to creating a healthier economy around relay operations, operators will not need to rely on grants and such to cover the cost of offering the service — permissionless relaying deserves a permissionless economy.
Beyond just performance, the Restaked Relayer plays a crucial role in preventing censorship, by minimizing the risk of a rogue relayer refusing to transmit certain messages or blocking specific accounts, the Restaked Relayer upholds the core principles of decentralization, ensuring that the network remains open, transparent, and accessible to all users.
In essence, the Restaked Relayer isn’t just about maintaining the speed of IBC on Initia; it’s about elevating the entire experience, making inter-blockchain communication not only faster but also more secure and reliable than ever before.
The Final Lap
It’s been a blast taking you through what makes Initia’s Rapid Relayer one of the best out there. As we’ve seen, it’s not just about being fast — it’s about creating a seamless user experience in the fast-paced world of blockchain. Rapid Relayer has already been running in production on our testnet, and with the mainnet launch around the corner, we’re ready to take things to the next level.
When mainnet comes along (soon), the game plan is to use Hermes as the primary relayer while deploying Rapid Relayer as a complementary fallback. Think of it like needing the regular road to get to the Autobahn — both are crucial, but the Autobahn (Rapid Relayer) is where the real speed happens when you need it most, especially when dealing with a massive backlog of unprocessed packets.
While it’s true that Hermes is slow when traffic spikes, it is still a very comprehensive piece of software for fair weather conditions. Plus, more battle-tested too, that’s an important consideration for softwares that is to play a crucial role in the stack. And on the other hand, Rapid Relayer is brilliant at the one thing it sets out to do, relay packets fast — it does miss out on a few features like support for ICA, creating and managing channels, etc.
Moreover, let’s not forget about restaked security through Milkyway, which aligns the incentives of Relayer Operators to do what’s best for the users. Operators are incentivized to provide top-notch service, no matter the workload, using the best tool for the job at hand — whether that’s Hermes or Rapid Relayer.
At Initia, every piece of technology we build is with one goal in mind: delivering an unparalleled user experience. We innovate not just for the sake of innovation, but to push the boundaries of what’s possible in inter-blockchain communication, ensuring that Omnitia users always have the best tools at their disposal.
Signing off for now, but stay tuned — we’ve got plenty more to share about interop. The rabbit hole goes deeeep. Catch you next time! 👋
Rapid Relayer GitHub: https://github.com/initia-labs/rapid-relayer
