Chromia: Consensus and 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:
- 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/
- 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:
The possibility of collusion between providers.
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