Deep dive into Nois Network 0.12.0 release

Nois Smart Contracts’ Payment Flow: The Missing Piece for a Sustainable and Reliable Randomness.

Introduction

We are excited to announce the release of the new version of Nois smart-contracts.
This release is very special to us as it is the biggest missing piece that is required to go on mainnet featuring the completion of the last step which is randomness payment.

Before 0.12.0, Nois did not enforce any payment system. Instead, the nois-proxy deployed on consumer chains required a proxy fee. But since the proxy has been and will always be a permissionless component, anyone could spin up their own proxy and request the beacon for free.

With this 0.12.0, we introduce a novel way of IBC payment that not only gives a lot of flexibility and auditability to the consumer and protocol but also allows to incentivise the IBC relayers that have long been doing the heavy lifting for free.

In this article we explain more in details what this new release brings to the chain.

New payment contract

Before diving into the details, it is worth looking at the big picture of the system with the new payment.

Now let’s talk about what’s interesting to know and follow the journey of a randomness beacon, from the moment an application requests it to the moment the randomness is available to be consumed by the app’s logic.

End to end flow

With this new release, the end to end round trip beacon flows from the consumer chain to the Nois chain and back as follows:

1. The Dapp sends a WasmMsg to the nois-proxy contract requesting a beacon that is created at a certain timestamp in the future and pays the proxy fees at the same time. The proxy fees are not necessarily the same as the fees needed to pay for the Nois randomness fees. They can even be paid in the native chain token. These fees are collected by the proxy operator.
2. The nois-proxy sends a CosmWasm IBC packet to the nois-gateway asking for a beacon released after the aforementioned timestamp and initiates an IBC token transfer to its corresponding nois-payment contract. Every nois-proxy has one nois-payment holding its balance sheet on the other side of the IBC channel.
3. One relayer forwards the beacon request packet to the nois-gateway on the Nois chain. The nois-gateway takes care of registering the beacon request job and debiting the payment-contract. The nois-payment is instructed by the gateway to burn half of the randomness fee, give 5% to the relayer and 45% to the community pool.
4. Drand releases the beacon round that the Dapp requested, the drand-bots fetch that round and submits it to Nois. This tx triggers the nois-gateway to send a callback via IBC to the nois-proxy which in turn sends a callback to the Dapp (within the same tx in the same consumer chain block).

This is how the flow looks like from an IBC perspective:

This seems all good but how does the nois-proxy know about the nois-payment contract or the gateway. How is the payment being enforced? Let’s start from the beginning and see how things get initially set up.

Initial IBC setup

With the changes from v0.12.0 a lot of magic happens during the initial nois-proxy -> nois-gateway channel creation handshake.

These are the steps that are involved in in the Nois IBC setup

1. A relayer creates an IBC client, connection and an ICS20 (token transfer) channel. This is needed for the proxy to pay the Nois fees in NOIS tokens over IBC.
2. The operator instantiates the nois-proxy.
3. The operator/relayer initiates a channel on the proxy side. And that triggers this communication flow establishing some base.

By the end of this. the nois-gateway has knowledge about the proxy and keeps count of the beacons that have been requested by the proxy (Will be needed for v0.14.0 for new features). The gateway also knows which nois-payment corresponds to which nois-proxy.
On the other side, the nois-proxy knows where to find the gateway and knows its nois-payment contract. It also received the price that is needed to pay for the beacon.

Conclusion

The release of version 0.12.0 of the Nois smart-contracts marks a significant milestone for the project, as it introduces a new payment system that provides more flexibility to the developers. With the new payment contract, users can now request a randomness beacon and pay for it using the proxy or manually depositing NOIS there. All this while incentivizing IBC relayers that have been doing the work for free. The end-to-end flow of a randomness beacon from the consumer chain to the Nois chain back and fourth is explained in detail, along with the initial IBC setup required for the system to work. Overall, the new release brings several improvements to the Nois ecosystem and is a step forward in creating a more secure and reliable randomness for the interchain.