How C4Coin Works
Why isn’t C4Coin using Ethereum?
C4Coin does run on the EVM, but it doesn’t use a PoW consensus like Ethereum. Instead it uses a custom proof-of-burn consensus that does not incentivize wasting energy on an increasing hashrate ceiling.
That sounds like proof-of-stake, which Ethereum should be moving to in the future anyways. In a few years all mining will be “virtual”.
That’s a good point, but C4Coin’s two-token PoB consensus and governance objectives extend well beyond saving energy. Let’s examine the core concepts of the network.
Just for a minute let’s first imagine that the C4Coin network did run on a PoS model. That is, recover a metric ton of CO2 emission, get a C4Coin as reward. Now that C4Coin is in circulation forever. This model treats the cutback of CO2 as an asset that retains its own value. But environmental work is really a one time event. As a corollary, the more that environmental work is redeemed for C4Coin, the less valuable the token becomes. Effectively, the token self-deprecates itself because environmental work recorded on the network incentivizes less work to be done in the future.
Instead we want a measured amount of environmental work to translate to a one-time unit of processing power on the network. This way, there must be a continuous stream of environmental work in order for the network to continue processing transactions. Think of environmental work like the “gas” of the network. Except it’s not the gas, because we would fall into the same problem as before — gas can be recirculated.
Introducing the two-token model. Specifically, CO2kn and C4Coin. Environmental work is redeemed for CO2kn, which is used to stake on the network in a PoS-like consensus protocol. When staking is complete, the CO2kn is burned and C4Coin redeemed in its place. C4Coin is the official currency and gas of the network.
Notice in the pretty picture that the circulation involves C4Coin, but CO2kn must continuously be injected into the system to keep the network churning out new blocks.
You may be wondering if everyone that receives CO2kn needs to participate in consensus in order to get their C4Coin. Though you can be a validator if you want, it’s not necessary in order to redeem a CO2kn. First of all, CO2kn is in fact a tradable token. Since its utility is to stake in consensus, there should always be a steady demand of validators looking to buy CO2kn, proportional to the activity on the network. In addition, it is possible to set up a proxy validator that will stake your token and return the C4Coin reward for a percentage cut. This can be a simple and trustless process mediated by a smart contract that locks your CO2kn and enables the validator to stake those coins.
Proxy validators will be the simplest way to trade CO2kn for C4oin at face value as the network is starting off. Therefore, we plan to host an altruistic proxy validator while the first few projects kick-off on the network, just to make it easier for newcomers to use the platform. Using this service may be as simple as selecting your stake preferences in a clean web UI and sending tokens using Metamask or a similar account manager.
Technicals
You can see the C4Coin PoB consensus protocol on github. We are working to keep as much of consensus as reasonably possible on-chain in smart contracts. Contracts are more easily upgradable than hard-forking the engine, and more transparent to users and developers. To participate in consensus, a user with CO2kn can join the public validator set by staking. The validator set follows similar rules as proposed in Casper the FFG. Staked tokens are locked and to withdraw, a request must be submitted with a delay period to prevent sybil attacks.
Randomly Selecting Validators
You may notice from line 94 of the finalizeChange() method of the PublicSet contract that a subset of validators are selected from the total public set.
The PBFT tendermint protocol operates most effectively at a critical level of validators. Too many and consensus becomes sluggish. Choosing a subset of validators is a safe strategy as long the accounts are chosen randomly. Randomness is a tricky concept on a distributed system, but good solutions do exist. C4Coin uses the Scrape mechanism which is designed not only to prevent cheating but can also ensure that a threshold number of validators contributed their share of the secret.
At the risk of dangerously simplifying the concept, I’ll give a high level explanation of why PVSS works and what the “publicly verifiable” part means.
Imagine a set of 6 validators upload their share of the random number. The final random number is generated as a sum of these shares (only in our example).
As a validator it would be easy to decide the final random number by waiting for all five other validators to upload their share and then solving for x. Remember, we are using this random number to choose validators for the next block, so if it’s not random, the security of the entire network is jeopardized. To patch the cheat, use a two step process.
- Each validator encrypts their share using their public key, and uploads that to be publicly viewed.
- Once all six encrypted shares are uploaded, the validators upload unencrypted value and the other validators verify that the encrypted and unencrypted messages match by encrypting the value with the validator’s public key.
If the encrypted message of the second step and message of the first step don’t match, it is obvious that the validator did not upload the original value. Scrape is publicly verifiable because along with the encrypted share, validators upload a proof that can be used to verify the encrypted share is valid. Cardano’s Ouroboros engine currently uses Scrape, along with more technical documentation on the subject.
Block Rewards
The total number of block rewards to be given to backup nodes will be capped at 5–10% of the total amount of c4coin to be generated. This creates a strong incentive to projects to be proposed and added to the network.
Backup Nodes
In the case that tokens are not being burned the network still need nodes to host it. We define another set of validators, called the backup nodes.
Any node can become a backup node by staking C4Coin. We do this since there may not be COTKN to be burned. Backup nodes will gas rewards as well as a portion of the block reward relative to the amount the committee has staked.
Backup nodes are randomly selected to propose blocks, similarly to the main validator set, but selection is weighted by the number of blocks a node has staked on in the past, instead of by the amount that the node currently stakes. That is, the only way to be selected is to compete to stake longer than other nodes. However, the payout will be greater if you stake more.
This leads to a dominant strategy for backup nodes to stake high and not withdraw. The staking makes it sybil resistant since it doesn’t give you any benefit to break apart your stake. However, just staking more doesn’t increase the chance of being selected.
Player 1 has 4 options (Stake Low, Withdraw Now), (Stake Low, Withdraw Later), … (Stake High, Withdraw Later) ← dominant strategy should be the latter , i.e. bottom right corner.
Since we have sibyl resistance in place, the question is what sort of selection function do we have that is a function of the blocks staked? One simple solution is to use the results of quadratic voting (QV).
In QV, voters can buy more votes for an issue if they have a stronger preference. The amount they can get should only buy them a marginal advantage (as outlined in this paper https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531).
To ensure that nodes that stake early or late do not get an advantage, we can use a selection function, S(x) =x
For example, assume you have the 7 nodes with following stake distribution:
D={16,16,16,4,4,4,4}
Map function S(x) onto the set and sum to get the total number of votes available: S(D)= {4+4+4+2+2+2+2} = 20
