This repository contains Solidity contracts needed to bootstrap and run Nerif Network.
Nerif Bridge consists of two types of contracts: system and operational (see below).
System contracts (blue ones) are needed to secure the network, such as staking contract, slashing mechanism, etc
Nerif Network uses distributed key generation (DKG) procedure for creating a common shared secret across all validators. The implementation of DKG within Nerif Network requires having on-chain logic in order to be fully decentralized. This logic is implemented inside the DKG smart contract and is used during DKG process.
This contract also implements SignerStorage mechanism in order to store the collective network address generated by DKG.
- Using a distributed key derivation: N parties participate in an interactive process that generates a secret key for each party and a single public key
- Any T parties can participate in an interactive process to produce a valid signature.
- It uses secret sharing, additively homomorphic encryption and zero-knowledge proofs to achieve trustlessness.
Implements the logic needed for validators to stake tokens and join the network. Basically, a validator has to store N amount of tokens in order to be a network participant, and it can be done using the staking contract.
Nerif Network has incorporated slashing protection functionality to address malicious validators using smart contract.
The reward distribution pool contract implements the proper rewards distribution logic that incentivizes validators to join and power the network.
Operational contracts (rest) are needed to make the network work: registry, signer storage, and gateway.
This contract provides several features to run the network such as billing mechanism, customer contract execution, workflows management, etc. Registry contract is an entrypoint of all transactions coming from Nerif Network.
The gateway contract is needed as a security entrypoint of all transactions coming from the registry to the customer contract. Basically, it checks that the given transaction is a part of the given workflow which belongs to the "trusted" user before forwarding it to the customer contract.
The gateway contract belongs to the network user and should be deployed and registered per registry by a user itself. Nerif App provides a well UX-ed interface that allows doing it easily.
Simple contract needed to store a collective address generated during DKG.
The first step is to initialize environment by running the following command:
$ make initThe command installs node packages, compiles contracts, and creates .env config file with default mocked values.
Those values must be replaced with the real ones.
The following command runs tests:
$ npm run testThe current hardhat configuration supports 3 ENV-compatible networks: Goerli, Amoy, BSC Testnet. More networks could be added if needed.
In this example, polygonAmoy is going to be a mainchain.
That means this network is going to be used for system contracts deployment as well as operational ones.
Other sidechains include operational contracts only.
In order to deploy to another chain, --network parameter should be changed.
The following command deploys all contracts in the proper order on all supported chains:
$ make deployNode: take a look at the Makefile
After system contracts are deployed on mainchain, the script asks to start DKG process in order to set up a collective signer address. This address is going to be used within another contracts across all supported chains.
During the network bootstrap, each node requests a DKG contract address in order to start the process. Each network participant (Nerif Node) must stake a specific number of tokens in order to join the network, and it should be done before starting the node. If the current validator have not staked, the node will ask for approval to stake tokens.
To verify contracts, you need to specify network, contract address and constructor parameters (if present).
$ npx hardhat verify --network <network-name> <CONTRACT_ADDRESS> <CONSTRUCTOR_PARAMETERS>
Or you can set VERIFY variable to true while deploying contracts to automatically verify them afterwards.
$ VERIFY=true make deploy
- Send rewards to the rewards distribution pool
- Fund the generated collective address OR ask validators to fund it