In one of the previous blog posts, we described how the NEAR to Calimero bridge enables interoperability between NEAR Mainnet and Calimero private shards, along with the overview of the architecture, features, and use cases for the bridge. In case you missed it, the post is here. In this article, we will explore an exciting new upgrade to the NEAR protocol and consequently to the NEAR to Calimero bridge as well.

‍

The big update coming with protocol version 59 is the NEP-364 which enables efficient signature verification as host functions. This is very important since it will reduce the gas spent when verifying signatures in the method for adding and checking the validity of received block headers on the light client contract, meaning that also more signatures will be able to fit in a transaction that is capped by a limit of 300TGas on NEAR.

‍

This means that the set of validators can be even bigger and that the bridge will work without significant logic change even if the blockchain becomes more decentralized than it is as of the time we write this post. It also means that on the same size of the validator set, with the upgrade, the same transactions will become much cheaper. First let's get a brief reminder of what the light client contract does since the new host function will benefit that contract the most, and since the light client contract is the backbone of the bridge, as prover and connector contracts directly depend on it, the bridge as a whole gets a boost.

‍

Light client contract

‍

The light client contract will accept block headers that are being relayed to it if the blocks meet certain validation criteria:

1. The height of the block is higher than the height of the current head;
2. The epoch of the block is equal to the epoch_id or next_epoch_id known for the current head;
3. If the epoch of the block is equal to the next_epoch_id of the head, then next_bps is not None; approvals_after_next contain valid signatures on approval_message from the block producers of the corresponding epoch;
4. The signatures present in approvals_after_next correspond to more than 2/3 of the total stake;
5. If next_bps is not None, sha256(borsh(next_bps)) corresponds to the next_bp_hash in inner_lite

Since Calimero is a customizable sidechain built on top of NEAR, all of these rules apply for NEAR light client blocks as well, and more about it can be read in the NEAR protocol specification as well.

‍

If all of the validation rules pass for a block header received via a function call to the light client contract, it is certain that the block merkle root can be stored in the contract. This is probably the most important data piece for the bridge since with this hash, it can be proved whether a certain transaction happened at any time in the history of the whole blockchain up to the block height of the verified block header. In case you want to see how we use this data in action, take a look at the prover contract that uses the light client merkle root hash for proving whether a transaction or receipt indeed happened. Here is a link to the prover contract that is open sourced and audited along with all other bridge contracts.

‍

Efficient signature verification

‍

In the current implementation of the light client contract, we are using two external crates for verifying signatures, the ed25519-dalek and the libsecp256k1. The libsecp256k1 is supported due to legacy reasons, more on it can be found here. Currently, all of the validators use the ed25519 public-key signature system. Here is the method that will be updated once NEP-364 lands on mainnet.

‍

In order for the bridge to work, Calimero light client contract is deployed on NEAR mainnet, and NEAR light client contract is deployed on the Calimero shard. For both blockchains, there is currently a limitation of 300 TGas per transaction. Although this can be changed by tweaking the genesis parameters for a specific Calimero shard (if there is a use case for it and the owner of the shard sees the benefits of it). For example, block creation time can be faster than on NEAR mainnet, but then the blocks need to be smaller. Likewise, block size, that is originally capped by 1000TGas limit on NEAR mainnet, can be increased, together with the transaction gas limit, but then the block creation velocity decreases. Also, any specific wasm instruction cost can be tweaked but it will have side effects compared to the original NEAR setup. It is exciting to see use cases the community will come up with the customizable Calimero shards. Here we will describe the limitations and benefits coming with NEP-364.

‍

For the Calimero light client on NEAR, signature verifications are currently expensive, for example, with around 50 signature checks the 300TGas limit is broken and the transaction will fail. An approximation of how much gas will be spent when calling the add_light_client_block method is 8 + 6*(number of block producers with valid signatures stake > ⅔ total_stake)
As with NEP-364 it is expected that signature verification will be 20-25x more efficient according to the benchmarks, it is expected that we will be able to support up to 1000 signature verifications in a single transaction, which is unlikely to be needed in near future. But also, it means that the case of more realistic 50 signature verifications can be done in ~23 TGas, compared to the current ~300TGas.

‍

For the NEAR light client on Calimero, all of the above holds as well, in case the Calimero shard is set up with the same genesis parameters, which is the default setup. But even if the block size or transaction limits get changed, the benefits of the new efficient signature verification still hold true.

‍

Conclusion

‍

Stay tuned for exciting news coming both on NEAR protocol and Calimero, as with protocol version 59, signature verification becomes 20-25x times cheaper gas-wise, which is expected in the coming weeks. Also, read more about the bridge in this blog post and in general about Calimero private shards here.

‍