Understanding Router Chain: An Overview of its Architectural Key Components
As Blockchain technology continues to evolve, the need for seamless integration between various ecosystems has become crucial. This has led to the introduction of the concept of “Bridging”, which aims to provide users with the best of all worlds. Router is a pioneer in recognizing the need for Blockchain interoperability and has made it their mission to integrate the entire Blockchain world, giving end-users the freedom to choose from the best ecosystems available.
To accomplish this mission Router Chain’s architecture has the biggest role to play which includes the Source Chain, Gateway Contracts at both ends, Orchestrators, Middleware Contract, Relayers and Destination Chains. All these components work together to provide a secure and decentralized interaction between contracts on different chains, leading to a seamless inter-blockchain experience.
This blog aims to clarify these various architectural components of the chain in a straightforward and comprehensible manner. Let’s begin with a brief introduction to the chain before delving into each component individually.
Presenting the Router Chain: The union of the Blockchain world
The Router Chain operates as a Proof of Stake (PoS) blockchain, sustained by a network of reliable validators who are rewarded for their efforts. In addition to its efficient operations, the Router Chain presents a revolutionary approach to resolving the issue of blockchain interoperability.
Featuring the Cosmos SDK, the Router Chain has fast block times, robust security mechanisms, and the security-focused smart contract platform, CosmWasm. This allows developers to develop new blockchain applications effortlessly or seamlessly transfer existing ones to the Router Chain.
What are the architectural components that make the Router Chain a unique and effective solution?
Each component has a specific role to play in the functioning of the Router Chain. For instance, Gateway Contracts facilitate the smooth flow of information from Source Chain to Router’s middleware contract, Orchestrators work as validators to verify and vote for the authenticity of the information received in a decentralized environment, while Relayers relay proposals from the Router Chain to a specific destination chain.
Despite having distinct responsibilities, these components collaborate to provide essential features such as decentralization, multilayer security, composability, and more.
Let’s take a closer look at the flow of the bridging logic from the Source to the Destination Chain.
1. Source Chain
The resident blockchain ecosystem of the dApp, intending to go cross-chain. The business logic is written in a smart contract of this dApp, which resides on this blockchain which we call as Source Chain.
2. Gateway Contracts
To understand the smart contract of the dApp , an interpreter called Gateway contract is made. The Gateway contract fetches the information from the dApp’s smart contract and passes it to the Orchestrators. The Gateway contracts are equipped with two key functions, RequestToRouter() and RequestFromRouter(), that enable the smooth flow of information.
The RequestToRouter() function allows the application contract on the source chain to send a message to its corresponding bridge contract on the Router chain, while the RequestFromRouter() function facilitates communication from the bridge contract on the Router chain to the application contract on the destination chain.
The Gateway contracts are critical to the functioning of the Router chain, enabling secure, fast, and efficient cross-chain communication and transactions.
3. Orchestrators
The Router orchestrators are key players in the Router chain system. They work in partnership with the validators to ensure the seamless processing of events from other chains. They listen to inbound events, verify their validity, and then forward them to the Router chain.
To be a part of the Router chain network, all validators must run an orchestrator. The orchestrator serves as a bridge, gathering events from various chains and transmitting them to the Router chain through a listener and dispatcher model. The listener gathers events, while the dispatcher forwards them to the Router chain. The orchestrators also check the validity of pending requests before they can be sent out.
Additionally, Orchestrators have a heavy workload and to handle it effectively, each orchestrator can run multiple listeners simultaneously. They use RabbitMQ as a communication tool between the listener and the dispatcher, which helps keep track of messages until they are received, making it easier to handle any issues without extra effort.
4. Inbound Module
The inbound module is responsible for connecting third-party chains to the Router chain. It checks if the validator running the orchestrator is part of the set of validators and if the request has already been received. If the request is new, it creates a new event. The module then calls the ClaimHandler() of the Attestation module and waits for votes from the orchestrators.
Once all votes are received, the inbound module processes them and calls the CosmWasm bridge contract. If the call to the bridge contract is successful, the inbound module changes the event’s status to “delivered” and sends out an event to show it’s been completed.
5. Attestation Module
The Router chain utilizes the Tendermint consensus mechanism, ensuring that each block is only processed if a minimum of 2/3 + 1 validators, determined by their voting power, give their approval.
In order to effectively facilitate cross-chain bridging through Proof-of-Stake, it is crucial to guarantee that at least 2/3 + 1 validators endorse incoming requests to and outgoing requests from the Router chain. The Attestation Module serves to fulfill this requirement.
6. Validator Set (Valset)
The Router chain utilises a validator set that includes a nonce, a list of validators, and the height at which the set was created. It’s important that this set is consistent across all Gateway contracts. Updating the validator set involves several steps.
First, the attestation module checks if the power of the validator set has changed by more than 5% at the end of each block. If it has, the module creates a new set request. Then, orchestrators confirm the request and send a transaction to update the set on all Gateway contracts.
The contracts will verify the signatures, replace the old set with the new one, and emit an update event. The orchestrators listen for this event and send a transaction to the Router chain, confirming that the update has been made on all chains. Finally, the Router chain updates its nonce in the Multichain module once it has received confirmation from the majority of orchestrators.
7. Multichain Module
The Multichain module keeps track of all the chains supported by the Router chain and allows for the retrieval of chain configuration information, including the Chain ID, Chain Name, Symbol, Token Price, etc.
To add a new chain, one needs to deploy a Router Gateway contract on that chain with the current validator set, create a governance proposal and send it to the Multichain module. If necessary, also deploy a ROUTE token contract on the new chain. Once the governance proposal is approved, the requested chain information will be added to the Multichain module.
8. Application-specific Bridge Contracts
The application-specific bridge contracts serve as a middleman between the third-party chains and the Router chain. These contracts, built with CosmWasm and deployed on the Router chain, have the necessary logic to process requests from one third-party chain and send them to another third-party chain through the Router chain’s outbound module.
To protect against fraudulent contracts, these contracts keep track of the chain ID and addresses of all the contracts that are allowed to execute their functions. Additionally, the Gateway contract always includes the “msg.sender” parameter in the request, which the bridge contract can use to verify the authenticity of the source chain application contract.
9. Token and Gas Price Oracles
In order for bridge contracts to function properly and create outbound requests from the Router chain to various third-party chains, it is important to have accurate information on the token and gas prices of these chains.
This information is provided by oracles on the Router chain, which play a crucial role in ensuring that the bridge contracts have up-to-date information on the third-party chains. The bridge contracts must be aware of the current gas price of the third-party chain and the price of the destination chain’s native gas token in order to create and submit outbound requests effectively.
10. Outbound Module
The Outbound Module helps the Router chain’s smart contract send its request to the destination chain’s contract. The process starts with the bridge contract sending a request to the Outbound Module, which is confirmed by orchestrators. When enough confirmations are received, the relayer sends the request to the destination chain.
The orchestrator then receives an acknowledgment from the Gateway contract and sends another request to the Outbound Module. After receiving more confirmations, the process gets completed.
11. Relayers
Relayers play an important role in the functioning of the Router chain. They are third-party entities that act as intermediaries to relay proposals from the Router chain to a specific destination chain.
The Router chain has a network of relayers that are operated by various entities, thereby distributing the responsibility of relaying information. Each relayer listens to the Router chain and relays data to the destination chains as needed.
Conclusion
As the number of blockchains continue to grow, users are becoming dispersed across them. Despite advancements in blockchain interoperability, cross-chain applications have not been able to reach their full potential due to challenges with current solutions. To unlock the full potential of these applications, a more flexible infrastructure is needed.
This is where Router V2 comes in, an innovative approach that promises to usher in a new era of cross-chain applications and maximise the potential of blockchain technology. We hope this blog was able to shed some light on how these Router V2’s different components operate, and why they are necessary.
Router Chain’s Devnet is now LIVE: https://v2.routerprotocol.com/
Keep us close at hand by following us on your preferred social media platform!
Website | Twitter | Telegram | Telegram announcements | Discord
