Application-specific Bridge Contracts: Building a Bridge to the Future of Blockchains
Router Protocol is a leading pioneer in cross-chain initiatives, developing a secure, scalable, modular, and composable framework for enabling interoperability across blockchain networks. The project’s Layer 1 blockchain, Router Chain, leverages Cosmos’ Tendermint as its validation mechanism. This validation is also applied to any cross-chain request flowing via the Router chain.
The success of Router Protocol’s ecosystem hinges on its architecture, which enables secure and decentralised validation between contracts on different chains. One of the key architectural components that facilitates this seamless flow of communication is Application-specific Bridge Contract, and this article will provide a brief overview of the same.
What are Application-Specific Bridge Contracts?
The application-specific bridge contracts are middleware contracts deployed on the Router chain that is built using CosmWasm (a highly secure smart contract native to the Cosmos ecosystem) and as well as Solidity. Include the logic required to process the inbound request from a Request originator Blockchain and forward the processed request to another blockchain via the Router chain’s outbound module. Suppose you are sending a transaction from chain A to chain B. The middleware contract on the Router chain will include the logic required to process the inbound request from the source chain (in this case, chain A) and forward the processed request to chain B (in this case, chain B).
To ensure that a faux contract doesn’t execute any of the functions in these contracts, a bridge contract should always maintain a mapping of the chainId and addresses of all the application contracts (deployed on the third-party chains) that can execute its functions. Along with the payload, the Gateway contract will always pass the msg.sender parameter, which can be cross-referenced by the bridge contract to determine whether the source chain application contract is genuine or not.
These contracts have three primary use cases. Firstly, receive inbound requests from the source chain, execute the necessary logic, and if required, forward the processed request to another chain via the Router Chain’s outbound module.
What are some use cases of Bridge Contracts, and why are they important for an Application?
Decentralised Cross-chain Read Requests
One of the most underrated, albeit important, aspects of blockchain interoperability is being able to read the state of contracts present on one chain (say chain A) from a different chain (say chain B). A good example of this could be a Soulbound Token (SBT).
Transaction Batching
Transaction batching can help a lot of applications cut costs for their cross-chain operations. Depending on the requirement of the application, Router can be asked to execute batches of transactions either directly on the Router chain or on the destination chains.
Batch Atomicity
Router V2 provides support for atomic batch delivery, i.e., for ensuring atomicity across multiple transactions in a batch to save users from the overhead of deploying wrapper contracts to handle multiple function requests. It is important to note that atomicity can only be ensured for batches submitted to a single destination.
How do these Bridge Contracts work?
Bridge Contracts and Oracles
In order to create and submit an outbound request from the Router Chain to an external destination chain, a bridge contract must be informed of the current gas price on the destination chain, furthermore, the bridge contract will need to know the price of the native gas token of the external chain for internal calculations.
To facilitate this, oracles are required on the Router chain to provide the latest token and gas prices of various chains. The oracles serve as intermediaries that can retrieve and report the current gas and token prices to the bridge contract. By utilising oracles on the Router chain, the bridge contracts can have access to real-time and accurate information regarding external chain gas and token prices. This feature helps ensure the efficient and cost-effective execution of cross-chain transactions.
Moreover, there's another intriguing role of Bridge Contracts -
Bridge Contracts and Expiry Timestamp
Application-specific bridge contracts play a crucial role in the efficient execution of time-sensitive requests. Let’s understand how -
To ensure the timely execution of outbound transactions, each request includes an expiryTimestamp, which sets the latest time by which the transaction must be executed. If the relayer does not pick up the transaction before the expiryTimestamp, the batch is discarded. The Gateway contracts also verify that the expiryTimestamp is greater than the currentTimestamp to avoid late transactions.
If the expiryTimestamp is not satisfied, the transaction is reverted, and an acknowledgement is sent back to the bridge contract. Application-specific bridge contracts can ensure the timely execution of time-sensitive requests by setting the expiryTimestamp close to the currentTimestamp.
Overall, this ability ensures that transactions are not in a state of limbo for a long time. The applications can rest assured that if a transaction doesn’t happen before the expiryTimestamp, it will definitely fail on the destination chain. Therefore, they can plan accordingly.
Conclusion
To sum up, the use of application-specific bridge contracts is a crucial stride towards realising seamless blockchain interoperability. These middleware contracts play an important role in executing crucial processes and transmitting cross-chain transactions in a cost-efficient and effective manner. By leveraging oracles, these contracts can access up-to-date and precise data on external chain gas and token prices, ensuring the smooth execution of cross-chain transactions. Additionally, the option to specify an expiryTimestamp in outbound requests gives application-specific bridge contracts a valuable tool to optimise the performance and cost of cross-chain transactions.
Lastly, do check our previous blogs for an in-depth explanation of our architecture, the underlying technology that powers our platform here -
Episode 1: Understanding Router Chain: An Overview of its Architectural Key Components
Episode 2: Gateway Contracts: A Key Enabler of Cross-Chain Action on the Router Chain
Keep us close at hand by following us on your preferred social media platform!
Website | Twitter | Telegram | Telegram announcements | Discord
