On providers and stakes - Chromia

We get a lot of questions about who runs nodes in Chromia and whether there's a possibility of staking. This article tries to clarify both these topics.

The hosting model
Chromia's model of dapp hosting can be described as follows:

Decentralized applications pay for blockchain hosting (one application might need more than one blockchain) to the Chromia system itself, which can be itself understood as a dapp or DAO of sorts.
The Chromia system acquires node capacity from providers. Nodes run by providers produce blocks, thus enabling dapps to run.
So the Chromia system effectively acts as an intermediary between dapps and providers. This model allows normalization of pricing, funding of public goods within the system, and maintenance of spare capacity. Since the system itself is completely transparent, this sort of intermediary position does not create additional risks or inefficiencies.

It is important that individual dapps (or their developers/users) do not negotiate contracts with individual providers, but instead simply use Chromia's mechanisms. Individual deals are hard to assess, they are inefficient in an informational sense and they increase risk of collusion.

Who are providers?
Generally speaking, providers are businesses which run nodes which run Chromia blockchains (both system blockchains and application blockchains).

It is important that Chromia tracks the owner of each node. If a blockchain is run on 1000 nodes, but all these nodes belong to a single entity, that's not decentralized. The blockchain can be taken down with a single click. Thus Chromia will schedule a blockchain to run on nodes from different providers. And for this reason all providers must have public identities and go through identity checks – otherwise a single provider can impersonate 100 different ones.

We expect there will be several tiers of providers, with different requirements set for each tier:

System (or root) tier providers run system blockchains, anchoring system and ERC20 gateway. Security of the whole system depends on system providers, thus they have highest requirements.
High-profile tier providers run high-profile (financial) applications.
Low-profile providers run low-profile applications, e.g. games.
Storage-tier providers store data. Data is pretty unique since no computation is involved and a single surviving copy is sufficient. It will likely be possible for individuals and enthusiasts to operate storage-tier nodes.
System and high-profile tier providers need to be businesses with existing operating history, good reputation, and capability of maintaining nodes in 24/7 mode. For storage-tier nodes, these requirements can be relaxed.

However, it should be noted that this system is not yet finalized. We would like to observe actual market conditions, such as demands of application as well as supply of providers before settling on a particular structure.

The stake
Providers will need to have certain amount of CHR deposited to a special 'stake' account to operate. It is used as a security deposit of sorts. It serves two purposes:

Aligning the providers' incentives with the health of the system as a whole. We want to discourage actions which make Chromia less useful. The value of the stake is dependent on the utility of the network, meaning that the staking provider has an incentive to maximise, or at least avoid disrupting, utility.
Penalization of bad behavior. If a provider's nodes go down, or worse, participate in a double-spend, a penalty will be withdrawn from the security deposit. This encourages providers to run nodes in a stable and secure way.
Does this mean that Chromia is Proof-of-Stake system? Yes and no.

It's worth noting that the CTO of ChromaWay/Chromia has been involved in PoS research since 2012 and co-authored a widely cited paper on the subject ("Cryptocurrencies without Proof of Work" by Iddo Bentov, Ariel Gabizon and Alex Mizrahi, 177 citations counted by Google). So Chromia can be understood as an evolution of PoS ideas, but it is NOT similar to other PoS/DPoS designs.

In most PoS systems stake is used as a sole Sybil control mechanism. But Chromia uses two Sybil control mechanisms reinforcing each other: it requires both public identities AND stake for providers.

The main difference is that having more 'stake' in Chromia does not result in bigger control or bigger payout. That is, even owning e.g. 90% of entire CHR supply does not give an entity control over Chromia, which would be the case in most other systems.

For this reason, neither influence nor payouts are proportional to stake in Chromia. So Chromia does not have "staking" in a typical sense. A provider is required to have a certain amount of CHR staked (depending on tier and number of nodes it runs), but having more CHR has no benefits.

Non-custodial stake delegation
Hosting providers are generally in the business of providing hosting services, not holding crypto tokens. Since providers might have limited amount of liquidity and capital, they might want to partner with CHR holders to acquire the amount of CHR required for the stake.

One of the main advantages of blockchain is the simplification and automation of a business deals, thus we plan to offer a smart contract which helps to arrange a deal between providers and CHR holders in a safe and transparent manner. Investors will be able to contribute their CHR to a particular's provider stake without transferring ownership of CHR to the provider.

A provider who is unable to fulfill stake requirements can open a stake fund for 3rd party contributions, offering a fraction of subsequent revenue to be distributed among contributors on pro-rata basis. Investors can then transfer CHR to a special account, which does not belong to the provider, but is associated with its stake.

This eliminates a risk of an "exit scam", i.e. a provider outright stealing staked CHR. However, the stake can be "slashed" in case the provider nodes misbehave – e.g. they go offline for a prolonged period of time, or participate in a double-spend attack. For this reason, investors need to be careful when choosing whether to get involved with a particular provider's stake.

A contribution to provider's stake can be understood as a vote of confidence vouching for reliability of a particular provider. This creates a market-based mechanism for provider choice, and stake slashing creates an incentive to choose reliable providers.

Community nodes
Ordinary users can also run Chromia nodes which can hold replicas of blockchains according to user's preference. Such nodes increase security and reliability of Chromia as a whole, as they:

Thwart attempts of small group of providers to collude against users
Provide back up copies of blockchain data.
For this reason Chromia will incentivize community members to run these replica nodes, paying some sum of CHR for each blockchain replica on a monthly basis. Initially, this compensation will be paid out of the promotion fund, as this is one of ways to distribute CHR to community members. Later some portion of dapp hosting fees can be directed towards the community nodes.

Numbers
We know that many would be interested to know how many CHR tokens will be staked. But this would depend on many factors, such as market demand for Chromia dapp hosting, so currently impossible to predict.

Currently we are only able to provide a ballpark estimate of stake requirements (consider them our educated guess):

System provider: at least one million CHR
Application node: 10000 CHR
Community node: 1000 CHR
Of course, this will be adjusted according to market realities.

On the compensation side, Chromia has 20 million CHR allocated for system node compensation fund. This fund will provide an additional compensation to system providers while the network is small. Our target is to have at least 10 system providers at MVP mainnet launch (see below) and later expand it to about 20. The target compensation for system providers is 200 000 CHR a year. Thus system node compensation fund can be sustained for at least 5 years, beyond that we assume the system should become mature enough for application hosting revenue to provide sufficient compensation.

Bootstrap mainnet vs MVP mainnet
The Chromia network will be rolled out in several stages.

The initial stage called "bootstrap mainnet" (also sometimes called "alpha" on forums, hereinafter BootstrapNet) is designed for on-boarding providers and testing the network in conditions which are close to production. It is not a fully functional production network.

To create realistic testing conditions, we need the network to have some value – that is, it needs to have a real CHR token. Without any value at stake, people will not take security seriously. On the other hand, we also need to minimize the damage if something goes wrong since we will still be testing things. For this reason we need to put a firewall between the BootstrapNet and ERC20 token which is available on the market – conversion between two forms of CHR tokens will go through a human review. Thus if e.g. CHR tokens are stolen on BootstrapNet they can't be instantly dumped on the market.

Besides running system chains necessary to onboard providers, BootstrapNet will also be able to run specially vetted dapps.

After BootstrapNet is sufficiently tested and the critical mass of providers is assembled, we can transition to MVP Mainnet which will fully realize the Chromia vision. On MVP Mainnet token conversion and dapp deployment will be fully automated.

The distinction between BootstrapNet and MVP Mainnet is important when it comes to stake requirements: BootstrapNet will start with zero stake requirement to make provider onboarding easier. Stake requirements will be subsequently introduced, initially at minimal level and then raised over time. By the time of MVP mainnet launch stake requirements should be fully in place.

The logic behind this incremental onboarding process is that we need to find the balance between providers' willingness to commit capital to Chromia and dapp hosting needs. Only the market can provide this data.