Chromia: Consensus & nodes

Consensus & nodes

Model overview

It is clear that the full node model doesn’t scale particularly well. If we require users to run a full

node which has a complete copy of the system state then dapps are severely limited in what

computations and storage resources they can use.

With the aim of achieving better performance at scale, we propose a model in which individual

dapps are hosted on a subset of validator nodes which establish consensus on any modifications

to the dapp state, and handle client queries. The system should permit any user to run a full

replica node if desired, but the system should not depend on these replica nodes for operations. []

Sybil control mechanism

The research done by our team indicates that commonly used Sybil control mechanisms like PoW

and Proof of Stake (PoS) are unsatisfactory : neither of them guarantees a sufficient level of

131415

Sybil attack mitigation, or even a particularly good measure of decentralization. Evidence

indicates that most PoW-based blockchains, including Bitcoin, might be de facto controlled by a

small group of entities. This problem is particularly bad for smaller cryptocurrencies which do not yet have an independent mining ecosystem. PoS also comes with no decentralization guarantees,

and DPoS in particular is prone to formation of cartels and bribery.

16

Thus instead of following commonly used approaches we will design Chromia consensus and Sybil

control mechanisms from first principles.

What Chromia is trying to achieve can be compared to cloud computing: an application which

redundantly uses multiple cloud hosting providers can be considered a decentralized application,

in the sense that failure or censorship of a single cloud hosting provider does not result in a

shutdown of the whole application. A cloud computing model also allows users to use thin clients

instead of hosting a complete replica of the application backend on their personal device.

The essential roles in the Chromia model are defined as follows. Chromia software runs on nodes,

physical or virtual instances of computing power. Nodes are controlled or perhaps owned by some

kind of individual, organisation, or collective which we refer to as a provider. Users connect to such

nodes to post transactions, query data or synchronize their private replicas.

A Byzantine fault tolerant network is distinguished from a merely fault tolerant network by its

ability to tolerate arbitrary and potentially malicious behaviour by network participants. The

concept of nodes is sufficient for designing a fault tolerant network, but to target proper Byzantine

fault tolerance we must account for conscious provider entities with the potential to coordinate

multiple nodes.

Crucially, to keep a dapp decentralized we need to make sure that the nodes which run its

blockchain(s) belong to different and non-colluding providers. In that case the application can

tolerate a subset of providers experiencing failures, being compromised or performing hostile

actions.

For this to work, network participants need to i) know which nodes each provider controls and ii)

make sure that providers are actually distinct. The latter cannot be done mechanically, but it can

be done socially. There is plenty of evidence that Microsoft and Google are different providers, but

there’s no mechanical way to prove it.

We believe that all decentralised consensus ultimately depends on “social consensus”. Fully

automated decentralised systems are a fantasy, in the end it is people who determine the rules of

the system. Chromia acknowledges this, and includes it as a fundamental design principle. In

practice, provider distinctness will be achieved as follows:

1. Initially, ChromaWay will select a set of distinct providers. We believe that our extensive

knowledge of blockchain and IT industry will allow us to choose well, and we are

incentivized to select providers that the users will accept. Users who are concerned about

provider uniqueness are welcome to do their own research and contribute to the decision

making process.

16 Delegated Proof of Stake, https://bitshares.org/technology/delegated-proof-of-stake-consensus/

1. Eventually, once the system has a sufficiently diverse set of providers, we will allow

providers themselves to vote to add new providers and the system will no longer depend

on ChromaWay as a gatekeeper.

Consensus:

Each blockchain within Chromia will be associated with a set of validator nodes which is a subset

of all nodes belonging to Chromia. This subset of nodes will run a BFT consensus algorithm. Since

the set size is limited, PBFT-like algorithms are the optimal choice -- they are well-researched,

work well with smaller sets of validators, and provide definitive finality, making reorganization

impossible.

However, there are two systemic risks with signature based consensus of this kind which must be

considered:

1. The possibility of collusion between providers.

2. The possibility that a majority of nodes might be compromised via a “zero-day” exploit of

some kind.

The former risk is extremely subtle, and is discussed at some length elsewhere in this paper. The

latter is generally difficult to defend against, the best approach is to encourage a diverse range of

software and hardware in the provider ecosystem. Even with mitigation strategies in place, the

threat is compounded by the behaviour of signature-based consensus under failure conditions. It

has been shown to be prone to catastrophic failure , meaning that a breakdown in consensus can

17

corrupt the chain to the point that it becomes very difficult to recover.

For this reason, we decided to implement an additional layer of protection by anchoring blocks in

a PoW-based blockchain, such as Bitcoin or Ethereum. This can be done cheaply, a single Bitcoin

transaction anchoring the entirety of Chromia every few blocks costs very little, and it will

guarantee that Chromia confirmation strength will be at least as strong as Bitcoin for blocks which

are anchored. For example, a user who prefers to rely on Bitcoin security can wait until an

incoming payment is confirmed via Bitcoin anchoring before they send goods.

Node compensation:

Dapps require computational resources and storage and should be able to pay providers for them.

Providers should be incentivised to offer high quality services to dapps at competitive prices.

Chromia will establish a marketplace where dapp developers and node providers can buy and sell

resources.

ChromaWay will act as a key node provider in the very early stages. New providers will join as the

ecosystem gathers momentum, with lower resource prices stimulating dapps and higher prices

stimulating providers. Eventually market equilibrium will be achieved. We estimate that in the

long run the cost of using node resources will roughly match the cost of cloud computing

platforms like AWS EC2.

17 https://download.wpsoftware.net/bitcoin/pos.pdf

https://twitter.com/teamchromia https://www.reddit.com/r/Teamchromia https://www.youtube.com/channel/UCM_FvcRzwoZUmc60fYFj.. https://www.instagram.com/teamchromia https://t.me/hellochromia https://www.linkedin.com/company/chromia
https://www.facebook.com/teamchromia
https://t.me/hellochromia
https://t.me/ChromiaRu