.svg){kind=small}
A blockchain bridge, otherwise known as a cross-chain bridge, establishes a connection between two distinct blockchain networks, allowing users to transfer cryptocurrency from one chain to the other. One of the major challenges faced by blockchain technology was the inability to interact with other blockchains. Although individual blockchains can operate smoothly as standalone entities, they are confined within their own domains and can result in high transaction fees and congestion. The use of blockchain bridges resolves this issue by facilitating token transfers and information exchange between two independent blockchain platforms without the requirement for a central authority.
The NEAR to Calimero bridge enables interoperability between NEAR mainnet and Calimero Private Shards. The main features of the Calimero network are privacy and near zero transaction costs, since the only cost of running the Calimero network is the infrastructure cost depending on the number of validators. On the other side, while low cost and privacy are great, much broader use cases opened up with the bridge. Besides having the standard ability of bridging digital assets (fungible and non-fungible tokens), what we built at Calimero implies a much broader sense of bridging - making generic cross-chain contract calls in realistic time (~5-15 seconds). There are a plethora of business use cases with performance like this. But first, let's dive into the specifics of the bridge and how such performance is possible.
The performance described in the introduction is achieved based on the bridge having the following properties.
A stateless relayer that can be run by anyone, reads block headers from a source chain and sends them to the light client contract on the destination chain. In order to have a bidirectional bridge between NEAR mainnet and Calimero Private Shard, at least one relayer from NEAR to Calimero and at least one relayer from Calimero to NEAR need to be running. The bridge is trustless because anyone can send the block headers to the light client contract, and such headers will be accepted only if all the proof of stake rules are verified.
The Calimero bridge observes events on the connectors and upon such events triggers relayers to send the newest block from source to destination chain. Some of these events will also trigger automatic proving of receipts. What allows for such a quick and frequent bridging are the characteristics of the NEAR protocol that has very fast block time, and the architecture of the automated Calimero bridge with its components, such as the relayers, bridge service, events indexer and the message queue.
The bridge is straightforward for usage. In order to bridge assets, a user or a DApp needs to send a single signed transaction only. Concrete examples on how to bridge (N)FTs or make cross-chain contract calls can be found here.
We believe that the Calimero bridge is the fastest bridge on the market currently. On average the assets get fully bridged in ~15 seconds, but there are cases when this gets to as low as 5 seconds. Don’t hesitate to book a demo with us.
Above is a high level image of all the components of the bridge. Let's dig deeper into each of them.
The relayer is probably the simplest component of the bridge. It receives blocks from a source chain and sends those blocks to a light client contract on the destination chain, establishing a bidirectional bridge between the chains. In order to accomplish this, light client contracts must exist on both chains.
The NEAR to Calimero relayer reads the latest blocks on the NEAR blockchain and sends (relays) those blocks to the light client contract on Calimero Shard. Similarly, the Calimero to NEAR relayer reads the latest blocks on the Calimero Shards and relays those blocks to the light client contract on the NEAR blockchain.
The light client contract will accept block headers that are being relayed to it if the blocks meet certain validation criteria - most notably each valid block header needs to contain at least two thirds of valid signatures of the epoch block producers. The contract does not need to verify every single block header for blocks that happened in the chain history, as long as it has at least one verified block header per epoch. Another useful property of the light client is that every NEAR header contains a root of the merkle tree computed from all headers before it. As a result, if you have just one valid block header you can efficiently verify any event that happened in any header before it. An event in this context is any transaction or receipt.
With the prover contract, any transaction or receipt that happened on the other chain can be proved, provided that the light client on the chain where the prover is deployed has a block header height that is higher than the block where such transaction/receipt happened.
The Prover takes as input the proof data that contain a merkle path to the block where the transaction/receipt originated and a merkle path to the transaction/receipt. Also, the height of the known block to the light client contract needs to be provided. This block needs to be ahead or on the block of the transaction that we are proving. With all of this the prover can calculate the expected block merkle root and compare it to the one stored in the light client block. To see the exact structures used, visit our docs.
The prover enables us to build a set of contracts for transferring assets from one chain to another. With that, Calimero supports transfering fungible tokens as well as non-fungible tokens from one chain to another. Also, via the Calimero bridge cross-chain/Shard calls can be executed.
In the image below are all the actions happening when a user or a DApp wants to bridge an FT from NEAR to Calimero. Just to remember, the user (DApp) initiated all of this by broadcasting just a single signed transaction on the NEAR mainnet.
To read about the details for the bridging process visit the docs or watch this talk from NEARcon 2022.
In order to use the Calimero bridge (transfer FTs, NFTs, or make cross-Shard calls) it is needed to set up permissions properly. Permissions are managed on a connector basis and at the beginning, all connectors are denied for all accounts. For each connector permissions are managed on both sides, on NEAR (for bridging from NEAR to Calimero) and on Calimero (for bridging from Calimero to NEAR). More details on permissions can be found here.
Since the bridge has up to 5 seconds finality time, the potential use cases are numerous. Let's explore 2 examples, one will be academic and another a more real world example.
With the Calimero bridge you can create a realistic chess game on-chain. A contract on the NEAR mainnet could match users that want to play. Once two players are matched a cross-Shard contract call is executed to the contract on the Calimero network, where the contract with the whole chess logic is implemented. Once the game finishes on the Calimero side, a callback is executed to the contract on NEAR mainnet. It should be emphasised that the scenario described here is practically impossible on NEAR (or Ethereum) simply because it would be too expensive to pay each move on the chess board on NEAR, and also too slow and too expensive on Ethereum. With the described example on Calimero, all the moves (transactions) on the chess board are essentially free. The only paid transactions are the initial two, where two players send to the contract on NEAR they register for playing, and the two transactions for making a cross-call are only ones being paid.
A more real world example would be: a publicly traded company is running a Calimero network. The company wants all the benefits of a blockchain. Since sensitive company data can not be stored on the public mainnet, they still want to have some amount of interaction with the public chain. Hence Calimero with its bridge comes as a solution. Let's say they need to hold a voting on some issue the share holders need resolution on. The voting can be done inside the company private Calimero Shard, while the end result can be read form the mainnet by setting up a contract on Calimero side that allows for cross-Shard calls. In this scenario, all the specific votes cast are unknown to the outsiders, but just the final verdict. Thus the privacy of voters is preserved, while doing the voting on-chain.
We’ve also written two examples of use cases for gaming and for DAOs.
At Calimero we have built a trustless, automated, easy-to-use and extremely fast bridge that can make cross-chain contract calls besides the standard token bridging. The future with such a bridge is full of opportunities, so don’t hesitate to book a demo with us. Also, you can read our documentation.
.svg)
