in 5 minutes
Innovation involves creating new things and improving old ones. Bitcoin revolutionized traditional transactions, computation, and communication. The rise of Bitcoin also led to the creation of Ethereum and thousands of other blockchains worldwide, enabling different solutions for numerous sectors of society.
However, one problem still needs to be solved: these blockchains need to communicate with each other.
Like e-mail, it would be very limiting if Gmail users could only send e-mails to other Gmail users.
This is where Router Chain comes in.
Router chain creates infrastructure for developers to create solutions that work on multiple blockchain networks with decentralization, scalability and security in mind.
Without Router
.svg)
With Router
Deepdive Router Chain in 5 minutes
The Router team first developed Router V1 in January 2022, a cross-chain bridge that connects different blockchains, allowing data flow between them.
Router V1 maintains a set of nodes that listen for events on the source chain, generate proposals, and submit signed proposals to the destination chain.
As time passed, the team encountered some challenges with V1:
In order to overcome those limitations, the team developed...
Router V2
(also known as Router Chain)
The Router chain is a blockchain powered by tendermint (Cosmos blockchain). As a Proof-of-Stake (PoS) blockchain, the Router chain is primarily run by a network of validators who are rewarded for being honest and keeping the protocol running smoothly.
The Router chain is built using the Cosmos SDK and encapsulates all the features of Cosmos, including fast transactions, mechanisms for security, and CosmWasm - a security-first platform for smart contracts or self-executing programs that run on the blockchain.
In addition to CosmWasm, the Router chain also has Ethermint - a Cosmos library that provides a way to run smart contracts in Ethereum, which is a different blockchain, on the Router chain.
What sets Router Chain apart from other inter operability solutions and blockchain networks?
01
CrossTalk
Router's CrossTalk library feature allows contracts on one chain to pass instructions to contracts deployed on another chain without needing to deploy any contracts on the Router Chain. This way, cross-chain messages can pass through without disturbing other product parts.
02
Network Security
Security is an essential aspect of any blockchain network. The Router Chain derives its security from its underlying tendermint consensus mechanism. Additionally, all communication between Router chain validators is secured by one of the most secure authentication mechanisms: ED25519, a public key signature system designed to achieve fast verifications without compromising security.
03
Read Calls & Modularity
Applications can implement their own security measures on top of the baseline security model provided by the Router Chain. This security layer can be configured based on different parameters, such as the type of call, source chain, transfer value, and latency sensitivity. With this modular security mechanism, applications can implement their own safeguards on top of the baseline security model, giving them more flexibility and control over their security measures.
04
Transaction Batching
Depending on the requirement of the application, Router can be asked to execute batches of transactions directly on the Router chain or the destination chains. This will help numerous applications cut costs on their cross-chain operations.
05
Additional Security Modules (ASM)
Applications on the Router chain have the option to build security modules on top of Router’s baseline security. This customizable security layer comes in the form of Additional Security Modules (ASM). Examples of ASM: (1) m-out-of-n multisig - this is a multi-signature setup where at least m out of n (e.g. 3 out of 5) authorized participants must sign off on a transaction for it to be considered valid or executed. (2) Optimistic verification - This approach focuses on detecting and preventing fraudulent activities or malicious behavior after an action has taken place.
06
MetaMask Compatibility
Unlike most chains built using tendermint, the Router chain will have full-fledged support for MetaMask, one of the most popular crypto wallets.
Users will be able to:
(1) Add the Router chain to the list of networks on their MetaMask wallet;
(2) Import their Router chain assets and balances to their MetaMask wallet; and
(3) Review transaction details and sign transactions directly from their MetaMask wallet while connected to the Router chain.
07
Cross-chain Meta-transactions
With Router, users can make gasless transactions. Applications on the Router chain can assign who pays gas fees. The fee payer can either be anyone among the application themselves, users or a third-party assigned.
08
Acknowledgement & Gas Refunds for Transactions
(1) Acknowledgements are simply receipts for your transactions. Applications can choose whether or not they want to receive acknowledgments on the source chain.
(2) Gas Refunds are when requests are validated on Router Chain, the bridge contract automatically refunds any extra fees. This allows applications to send extra gas limit as a buffer, with the assurance of automatic refunds for excess fees.
Stateful and Stateless Bridging
Stateless
For decentralized applications (dApps) that don't need any additional custom bridging logic or data aggregation layer between different chains, middleware contracts are not required.
Stateful
For cross-chain dApps that require custom bridging logic between two chains, developers can create and deploy middleware contracts on the Router chain. When a cross-chain request originates from the dApp's source chain contract, it is directed to the middleware contract on the Router chain. This middleware contract can perform certain actions before forwarding the request to the intended destination chain.
CrossTalk
Router's CrossTalk is a cross-chain framework that allows contracts on one chain to pass instructions to contracts deployed on another chain without needing to deploy any contracts on Router Chain. With just a few lines of code, applications can transform their existing single-chain and multi-chain applications into cross-chain applications.
Before we get into how CrossTalk works, let’s breeze through the types of requests that can be sent through CrossTalk first:
.svg)
01
Single-call Request
A request that includes only one contract call for execution on the destination chain.
This is like sending 1 letter to the post office.
02
Multi-call Request
A request that includes multiple contract calls for execution on the destination chain.
This is like sending multiple letters to the post office.
03
Requests without Acknowledgment
An acknowledgment is not required on the source chain after the request is executed on the destination chain.
This is like choosing to not get a confirmation for the delivery of your letters.
04
Request with Acknowledgment
If an acknowledgment is required on the source chain, developers need to specify whether they want an acknowledgment only in the case of a successful call, a failed call, or in both cases.
This is like choosing to get a confirmation for the delivery of your letters if your letters were delivered successfully, unsuccessfully, or both.
Now let's explore how a cross-chain transaction happens. But before that, quickly review our glossary of terms here.
A cross-chain request through Router Chain involves three components: source chain Gateway contract, destination chain Gateway contract, and Router chain.
To understand the process, think of it like sending a letter from one city to another.
For example, Joe lives in New York City and wants to send a letter to his mother in Chicago. To make this happen, Joe must write the letter, bring it to the New York Post Office, and pay them. The New York Post Office will transfer the letter to the Chicago Post Office, then a postman from the Chicago Post Office will send a deliveryman to deliver the letter to the home address of Joe’s mom. Once the letter is delivered to his mom, the New York Post Office informs Joe of the successful delivery.
In this scenario:
Joe = User
Joe's letter = Source chain request
New York Post Office = Source chain Gateway contract
Chicago Post Office = Destination chain Gateway contract
Deliveryman = Router Chain
Chicago = destination chain
Payment to post office = Fee payment
Confirmation of delivery = acknowledgment request
Let's now take a closer look at its operation. The entire process can be summarized in the diagrams below.
1. Initiation: User initiates a cross-chain action on the application's smart contract on the source chain, the smart contract then interacts with the Router Gateway contract.
2. Listening: The Gateway contract on the source chain emits an event that orchestrators on the Router chain listen to.
3. Fee Payment: Once the event is validated, the Router chain deducts the fee from the designated fee payer's address on the Router chain. The fee payer is responsible for paying fees for the cross-chain requests.
4. After the fee deduction,
a. If the destination chain is a third-party, relayers pick up the signed transaction from the orchestrator and forward it to the Router Gateway contract on the destination chain.
b. If the destination chain is the Router chain itself, the request is sent to the designated contract on the Router chain.
5. The Gateway contract on the destination chain interacts with the application contract on the destination chain.
6. Execution: Once complete, the Gateway contract on the destination chain emits an acknowledgment event that orchestrators on the Router chain listen to.
7. Fee Refund: After validating the acknowledgment event, the cross-chain request is marked as completed on the Router chain, and any excess fee is refunded to the fee payer's address.
8.Acknowledgement: If the application requests to receive the acknowledgment on the source chain, the relayers send it to the Gateway contract on the source chain, which sends it to the application’s source chain contract. Otherwise, it is discarded.
1. Initiation: User initiates a cross-chain action on the application's smart contract on the source chain, the smart contract then interacts with the Router Gateway contract.
2. Listening: The Gateway contract on the source chain emits an event that orchestrators on the Router chain listen to.
3. Fee Payment: Once the event is validated, the Router chain deducts the fee from the designated fee payer's address on the Router chain. The fee payer is responsible for paying fees for the cross-chain requests.
4. The application-specific bridge contract interacts with the validated event, applies middleware custom logic, then splits into two legs:
Router chain to source chain
The middleware contract emits an acknowledgement event for the source request listened to by Router orchestrators
After validating the acknowledgment event, the source chain request is marked as completed on the Router chain, and any excess fee is refunded to the fee payer's address.
Relayer picks up the acknowledgement transaction and sends it to the source chain.
Gateway contract sends an acknowledgement to the application contract.
Router chain to destination chain
Relayer picks up the CrossTalk request and sends it for execution on the destination chain.
Gateway contract interacts with application contract.
Application contract executes relevant logic
Router chain orchestrators listen to the acknowledgement event for the destination request emitted by the Gateway contract and validate it on the Router chain.
Future of Inter operability
Instant Finality: Router Chain can help prevent transaction rollbacks with its instant finality feature, making cross-chain transactions faster and more secure. This means that cryptocurrency transactions can be sent urgently and without the risk of being taken back.
Interoperability with private blockchains: Router Chain is developing a way for private blockchains to share information with larger, public blockchains securely. This helps increase private blockchains' safety by leveraging public blockchains' security.
Automated triggers: Router Chain's scheduling service automatically executes specified contract functions without an external trigger, once implemented. This unique feature can be used for various purposes, such as triggering buy and sell functions based on monitored token prices.
To dig deeper into Router Chain, explore their full whitepaper.
Glossary
Now that you know what makes Router Chain unique, let's explore how a cross-chain transaction happens. But before that, quickly review our glossary of terms here.
Application smart contract
These are contracts deployed by applications on third-party chains and serve as the intermediary between end users of the application and the Router chain.
Chains
Source chain - the blockchain where an asset or data is currently held or originated from.
Destination chain - the blockchain to which the asset or data is being transferred or deposited. For example, if a user wants to transfer tokens from Ethereum to Cosmos, Ethereum would be the source chain and Cosmos would be the destination chain.
Custom Logic
The ability to program specific rules and behaviors into a blockchain network.
Event
A notification that something has occurred within the system. It usually means the completion of a task or the occurrence of an error.
Fee Payer
The address that paid the transaction fee.
Listen
The act of monitoring or observing activity on the blockchain network.
Orchestrators
They listen and forward inbound events from other chains and attest the validity of outbound requests before relayers pick them up. All validators must use an orchestrator to participate in the Router chain ecosystem.
Relayer
This helps move requests from the application to the destination chain.
Router Gateway Contracts
As their name suggests, these contracts act as a gateway for the movement of funds and messages between external chains and the Router chain.