Router Chain’s New v.1.1 Whitepaper
Exploring the Dynamic Architectural Update of the Chain
As the testnet phase of the Router Chain unfolds, our team has been working to optimize the architecture for seamless cross-chain workflows. These efforts have resulted in a series of significant updates that have (a) improved our throughput, (b) optimized our costs, and © made our offering more developer-friendly. This blog will explore the new Whitepaper, which incorporates the recent architectural update.
The Recent Architectural Update
To understand the new update, let’s briefly recap the Router Chain’s flow; it has three major flows — Inbound, Outbound, and CrossTalk, each with a different function call and different modules for handling their execution.
The Inbound flow handles the transmission of requests from other chains to the Router chain, whereas the Outbound flow forwards requests from the Router chain to other chains.
Router empowers applications to exert greater control over their business logic through middleware contracts positioned between the Inbound and Outbound flow. The third flow, the CrossTalk workflow, is enabled by our CrossTalk module, an easy-to-integrate smart contract library that allows developers to build cross-chain applications without any custom bridging logic.
However, during our internal testnet, we made further improvements and standardized the function parameters. We merged the Inbound, Crosstalk, and Outbound into a unified flow on the implementation side. This resulted in reduced size of the Gateway contract and much lower gas costs while interacting with it. Now, developers can simply pass their request information using a single function. The Router Chain will decode it as metadata and data information, transforming the request for the destination chain. This enhanced compatibility allows us to add support for new types of chains much more easily.
Initially, the integration of Ethermint resulted in an increased block time (from 3 seconds to 30 seconds). As part of this update, we have made changes in the Ethermint implementation to bring back the block time to under 3 seconds. To further optimize our block time, we have also tweaked our re-execution logic for pending transactions. Earlier, we used to retry all the pending transactions in a block at the end of that block itself, which used to result in higher block times. Now, we maintain the pending transactions in a separate block queue, which is executed after every X blocks (where X is a configurable parameter currently set to 300).
In addition to the aforementioned changes, we have introduced batching for the orchestrator, which has allowed for an increased TPS (transactions per second) for cross-chain requests. Now, instead of forwarding every cross-chain request from a chain as it comes, we wait for either 100 requests from that chain or Y seconds (whichever happens first), batch all the requests and then forward the batched request to the Router chain. Note that Y is a chain-specific configurable parameter currently set to 20.
About Router Protocol
Router Protocol is a pioneering cross-chain solution that enables secure and efficient communication between blockchain networks. The L1 Router Chain uses Tendermint’s BFT consensus to address interoperability challenges while enhancing security and scalability through decentralization. The Chain enables cross-chain meta transactions, stateful bridging, transaction batching, and batch atomicity, providing a modular framework for building cross-chain dApps in web3. The use cases range from cross-chain NFTs, cross-chain governance, and cross-chain stablecoins to cross-chain oracles and cross-chain marketplaces and many more
Read our Whitepaper here — https://routerprotocol.com/router-chain-whitepaper.pdf
Stay tuned for more updates, and keep us close at hand by following us on your preferred social media platform!
Website | Twitter | Telegram | Telegram announcements | Discord
