What is EOS: Beginners Guide Part 2
Welcome back to the second part of our EOS IO Dawn 4.0 guide.
We have already discussed the following:
- The RAM Marketplace
- Future Parallelism DPOS
- Header-only Validation
In the second part we are going to talk about:
- Block Producer Rewards
- Vote Decay
- Last Irreversible Block Algorithm
#4 Block Producer Rewards
We have already told you how the DPOS consensus mechanism in EOS works. For a quick summary, EOS network has 21 block producers and those 21 take care of consensus and network health. Traditional consensus mechanisms like proof of work(POW) and proof of stake(POS) have a more immediate reward system. Having said that, EOS’s DPOS doesn’t really have anything like that. Instead, it has an inbuilt inflation system which increases the overall supply by 5% every year.
These surplus tokens are then distributed accordingly (more on that in a bit).
According to Block. One, this inflation system is the way to go forward for the long-term development of the EOS project.
EOS Reward Distribution
Image Credit: Medium
Hmm..what is going on here?
The inflation rate of EOS per year is 5% which is divided into two parts:
- 1% which goes to the producers.
- 4% which goes for worker proposal systems (more on this in a bit.)
The main logic behind the distribution algorithm is to make sure:
- The producers are paid sufficiently for their service.
- No one is paid in an insufficient way to not cover their costs.
- Everyone who qualifies must get a minimum per day payment so that “wealthy individuals who have no intention of producing blocks don’t attempt to earn interest on their producer candidate by voting on themselves.”
Like we have mentioned, there are 21 active block producers, however, there can be any number of standby producers as well, who may have received a certain number of votes in the election, however, they weren’t able to qualify in the top 21. So this is where things get interesting. The 1% that is meant for block producers gets split into further two parts:
- 0.25%. (Block Rewards)
- 0.75% (Vote Rewards)
All the 21 block producers are entitled to the 0.25% block reward in proportion to the number of blocks they discover.
Now what happens to the rest of the 0.75%?
It gets distributed among the 21 block producers and the rest of the standby producers in accordance with the number of votes they get. However, before that, some conditions have to be met:
- The producers who get the reward have to qualify for at least 100 EOS tokens.
- The vote rewards have to go out at once daily.
Let’s see how this reward mechanism is going to help block producers being more valuable to the ecosystem.
Suppose, Alice and Bob are two competing producers. If Alice brings in more value than Bob, the network will recognize her worth and give her more votes. On account of having more votes, Alice will receive more voter rewards. This, in turn, will incentivize Bob to step up and produce more value, so that he can get more votes, and subsequently more rewards, the next time around.
You can check the number of active producers in the EOS network over here. As you can see, there 55producers (as of writing) who have qualified (>100 EOS/day) for the voter rewards.
What Happens to The 4%?
As we have already told you, 4% of the inflation rate has been kept for the “worker proposal system.” Now, 4% is a lot of money. Consider this, 50 million EOS tokens are going to enter the market as inflation in the first year itself, of which 40 million EOS tokens will be used for these worker proposal systems. At current valuation, that stands at roughly $400 million USD.
That’s a HUGE amount of money so it makes sense to understand where that money is going to be used.
Turns out, you can do pretty much anything you want with that investment!
The EOS community votes on how to use the funds going forward. Here are some of the ideas that are circulating in the community. Most of the funds will be used for research and development on the EOS blockchain but there are also proposals of keeping some of the tokens for charitable and relief purposes.
There is another interesting proposal.
In a 5-year period, the number of EOS tokens will balloon up to 1.276 billion EOS tokens, which is ~300 million tokens of surplus which, at current valuation, goes to ~$3 billion!
Now, the thing is, the injection of so much EOS tokens is going to shoot supply through the roof, which in turn, imbalances the “supply || demand” ratio. An interesting proposal is to inject a token-burning mechanism which burns excess tokens and keeps the token supply in check.
It looks like EOS has a pretty well thoughts out reward mechanism. it will be interesting to see the kind of projects and innovations that may come about as a result of the worker proposal system.
Up next, we got Voter Decay!
#5 Vote Decay
Before we get into it, it is important to understand why voting is such a critical component of EOS.
EOS and Voting
The reason why EOS was created was to support industrial-scale Dapps. It is important to know what the word “industrial-scale”. EOS uses DPOS with 21 block producers so that they can scale their platform up enough to support these kinds of Dapps. The importance of these block producers definitely can’t be underestimated. Not only do they take care of consensus, but they take care of overall network health as well.
In EOS, you stake your tokens for resources such as network bandwidth, CPU bandwidth, and RAM. If the value of the tokens increases threefolds, your access to these resources shouldn’t be affected post staking.
But what happens if you don’t own the tokens and are simply securing resources for your Dapp, what happens to you if the token price rises? In cases like these, it is up to the block producers to maintain the relationship between resources and tokens. The producers must work on bringing the cost per unit of resource down to a reasonable range.
This is, arguably, the most important task of the BP and this is the reason why BP voting is such an important task. However, before we continue, we need to know why it is important for people to vote and for their votes to actually mean something.
Voting Apathy and The Free Rider
Voting is the lifeblood of modern democracy. The same is true for a decentralized system like EOS.
However, voting generally falls victim to the free-rider problem. The “free-rider problem” is a concept in game theory where
“those who benefit from resources, public goods, or services do not pay for them, which results in an underprovision of those goods or services.”
Let’s see an example of this to understand the concept, after that we will see how this works wrt voting.
The free rider problem works on public goods/services which are:
- Non-Excludable: People can’t be prevented from using these goods.
- Non-Rivalrous: One person’s use doesn’t diminish the ability of another person to use the same good.
Let’s think of “National Security” as this public service. Ideally speaking, as a citizen, you should be paying taxes to the government regularly so that they can use it to maintain and improve the army. However, what happens if you don’t pay these taxes?
Even if you don’t pay these taxes, you will still “get” national security and the army will still fight at the borders regardless. In essence, you become a free-rider.
The problem is that as more and more free-riders enter the market; it could lead to dire consequences. The government may not have enough money to invest in their army and you can imagine how dire the consequences can become.
So, how does that factor into EOS voting you ask? Well, let’s take a pretty recent example.
A very common reaction that one gets from someone when asked why they didn’t vote is: “My vote will not change anything.”
The thinking behind this logic is that since there are so many people voting, one single vote will not make any difference.
However, we already have seen the problem with the increasing number of free-riders.
One need not look any further than the 2016 US Presidential Elections contested between Hillary Clinton and Donald Trump. Only 56.9% of the eligible population bothered to turn up for the elections.
Image Credit: Statista
This kind of voter apathy could be extremely detrimental for EOS. As we have already seen how important producer elections are. In order to make sure that the best block producers are put in charge, the EOS participants should take part in the elections in an active way.
However, that is an extremely idealistic viewpoint. Something needs to be done to make sure that each and every vote actually means something. This is the reason why EOS creator Dan Larimer introduced the concept of “Vote Decay.”
By implementing “Vote Decay” the following happens:
- Power of each vote halves every year
- Voter must recast their vote every week to reassert the strength of each vote.
- Circumvents the “free-rider problem” by giving the voters a chance to re-evaluate their votes.
The Voter Decay mechanism leads to two great advantages:
- Firstly, as we have seen time and again, elected officials may become corrupt and change their tune after getting elected. The vote decay system gives the voters a chance to reconsider their vote every week. This keeps the block producers accountable and on their toes.
- Secondly, people simply change over time. Maybe the political beliefs and ideologies that someone has today is completely different than what they had a year ago. The vote decay system will allow people to vote for someone who is more congruent with their newly evolved ideologies.
This has the potential to be a truly revolutionary concept and can change decentralized voting (maybe even voting) forever.
Like we already mentioned, the power of each vote cast halves every year. SpringRole CEO, Kartik Mandaville, showed how this will work on his Medium article:
“The base time for the calculation of weight is Jan 1st, 2000. Now instead of rewriting the weighted vote to the blockchain every time, Dan came up with the idea of increasing the weight of the future votes. eg Jan 1st, 2019 is 2¹⁹ and Jan 1st, 2018 is 2¹⁸ — this makes the vote on Jan 1st, 2019 twice as powerful as Jan 1st, 2018.”
One of the most interesting concepts that EOSIO Dawn 4.0 has brought to our attention is the “Voter Decay” model. It is believed that this could potentially be a very powerful model that future blockchain projects can use to implement a voting mechanism.
The vote decay is one of the most intriguing things to have come from EOSIO Dawn 4.0. A potential problem could be the use of bots for the voting protocol, however, Dan Larimer addresses it as such:
“We recommend that the constitution contain language forbidding the use of automated voting bots as the purpose of vote-decay was to ensure that voters re-evaluate their decisions rather than “set-it and forget it”. While it is not possible to prove the use of bots, it will be possible to prove that people do not use smart contracts to auto-vote.”
#6 DPOS Last Irreversible Block Algorithm
There are quite a few things that must be covered before you can understand DPOS Last Irreversible Block (LIB) Algorithm. Before we even begin, we must know what finality is.
Finality, in very loose terms, means that once a particular operation has been done, it will forever be etched in history and nothing can revert that operation. This is particularly important in fields which deal with finance. Imagine that Alice owns a particular amount of an asset in a company. Just give of some glitch in the company’s processes, she shouldn’t have to revert ownership of that asset.
If you were to classify blockchain consensus algorithms, they would fall under two categories:
- Given a defined set of validators, they produce 100% unambiguous finality.
- Those that do not provide 100% finality but rely on the high possibility of finality.
The first generation of blockchain consensus algorithms such as Proof of Work (POW), traditional Proof of Stake(POS) etc. offered a high probability of finality without any 100% guarantee. Think of a POW coin like Bitcoin.
Bitcoin follows the “longest-chain” rule, meaning, even if the blockchain branches out into multiple chains, the chain which has the maximum amount of blocks will be considered the main chain. Because of this reason, none of the blocks mined are exactly irreversible in every sense of the word. Anyone anytime can build a longer chain given they have enough resources and motivations.
Bitshares introduced the world to Delegated Proof of Stake aka DPOS. A DPOS blockchain typically has 100% block producer participation. A transaction is usually confirmed within 1.5 seconds from the time of broadcast by a 99.9% certainty. In order to have absolute certainty over the validity of a transaction, a node need only to wait for 15/21 (i.e. a 2/3 majority) producers to arrive at a consensus.
So what happens in the event of a fork caused by negligence or malicious intent?
All the nodes will, by default, not switch to a fork which doesn’t include any blocks not finalized by 15/21 producers. This will stand true regardless of chain length. Each block must gain a 15/21 approval to be considered a part of the chain.
Because of the short block creation time, it is possible to warn nodes of whether they are in the major or minor chain within 9 seconds. The reason why that is so is simple. Remember, the average time elapsed between each block is 3 seconds .If a node misses 2 consecutive blocks there is a 95% chance that they in a minority fork.
While this was definitely an amazing innovation, DPOS 2.0 took things to a whole new level. DPOS 2.0 started the concept of the last irreversible block (LIB). The LIB is the most recent block which 2/3+1 of the bock producers have built off of. The logic is that if the majority of the producers have built on a chain then the likelihood of the fork will go down even more.
Having said that, this LIB has an attack scenario. Consider the following:
- The network splits into two chains.
- Normally, this would cause one or both the chains to halt until one of the chains gain approval from 2/3+1 producers.
- However, what 2 subsets of validators simultaneously switch forks which results in both the forks reaching 2/3+1 on 2 different blocks.
- Because of this, there is a possibility of 2 different LIBs which defeats its process.
Even if this failure mode’s probability of occurrence is much less than the probability of a Bitcoin block with 6 confirmations being reversed. Both Bitshares and Steem which have operated for over 3 years without this problem situation ever being observed.
This is where DPS 3.0 comes in with IBC. IBC will help one chain to prove to another chain the finality of its transactions. Finality is a crucial and critical element for smooth IBC.
In order to secure reliable IBC despite all conditions, DPS 3.0 and BFT introduces a slight modification to the LIB algorithm. With this slight change, one can prove indefinitely that 2 nodes can’t come to different conclusions regarding the LIB. As a result, it also helps prove the malicious behavior of each node.
In DPOS, each and every block that gets created is essentially a stamp of approval for a previously mined block. So, if 70% of the producers have built on a block, then that block has 70% of the votes and approval in the ecosystem. This seems pretty sound, however, this is where we hit a snag. Turns out, that in a DPOS system, producers may, maliciously or otherwise, produce blocks on different forks at different. This ends up conflicting the votes achieved by previously discovered blocks.
Let’s consider a scenario and check how this would have been handled in both DPOS 2.0 and DPOS 3.0
- Consider a network with 3 producers: A, B, and C.
- Suppose there is a loss of communication between producers A and B and they both end up making Block N at Time T (for A) and Time T+1 for B.
- Now C creates block N+1 at time T+2 on top of B’s Block N.
- A realizing this, creates Block N+2 on top of C’s Block N+1 conflicting his previously mined Block N.
Let’s look at the above scenario wrt to both DPOS 2.0 and DPOS 3.0.
Under DPOS 2.0
The number of total producers on our fictional network is 3. To get the 2/3+1 majority in this network, all 3 people will will need to consent (2/3*3 +1 = 3).
So, for block N from A to get approved in the network, it would have been deemed irreversible if it got mined on by all the producers.
Under DPOS 3.0
Remember the key points of what happened earlier?
- A and B discovered block N.
- B’s block N got built upon and A’ block was ignored.
- In fact, A also built on B’s block.
Under DPOS 3.0 however, the following will happen.
- A will confirm that he produced an alternative block N.
- Because of this disclosure, the network will not count A’s block N+2.
- Since this leaves B’s block N with only 2 votes instead of 3, it makes the block non-irreversible.
So, how is this implemented?
- Each producer includes the highest block number (H) that they have previously confirmed on any fork in their block N’s header.
- When the block N is applied only the block in the range of H+1 to N is considered for irreversibility.
- Anyone who tries to do malicious behavior by signing a block with a different range is labeled byzantine and generates a cryptographic proof of misbehavior.
- For two different blocks at the same block height to achieve 2/3+1 votes, the group needs to be divided threeway into 1/3, 1/3, and 1/3. One group of 1/3 produces one block, the other group produces another block while a malicious group of 1/3 signs for both the blocks.
However, in this situation, the network must have 2/3+1 to be malicious to create two blocks which are deemed irreversible. There are only two ways that it can happen:
- Sign two blocks with the same block number directly or indirectly.
- Sign two blocks with the same block time.
Newer consensus protocols like DPOS, Hashgraph, Casper, and Tendermint manage to achieve unambiguous finality as long as 2/3rd of the participants are honest. 100% unambiguous finality is a critical feature for blockchains who want to support IBC. The abstract blueprint for all these protocols involves:
- Block proposal.
- All the participants issue pre-commitment on the block.
- All the participants when >2/3 acknowledge the pre-commitments.
- Block achieves finality when >2/3 commitments are reached.
- Finality agreement is reached unless >1/3rd are malicious and the evidence of bad behavior is available.
Vitalik Buterin, the man behind Ethereum, pointed out some possible vulnerabilities in the EOS consensus mechanism. He said:
“This does not seem to actually be safe. Consider a case with four validators, so we are allowed one byzantine. Suppose before time T the commonly agreed head is Z; then, at times (T, T+1, T+2, T+3), validators (A, B, C, D) make blocks extending a chain from Z. A now has votes from B, C and D and so is finalized. Now, before timeslot T+3 ends, D also (byzantine-ly) makes a block (call it D’) on top of Z. Then, at times (T+4 … T+11), (A, B, C, D, A, B, C, D) make blocks on top of D’ (this is ok because each validator is making a block at a height one higher than the block they previously made). The second A block in this chain has three votes and so is also finalized. Hence, two conflicting blocks got finalized.
In general, it’s not possible to achieve BFT safety on a block without at least two messages from most nodes that directly or indirectly reference that block; this algo tries to do it in one round and it’s likely impossible to actually do that safely. If you want an intuitive and good way of doing this, I recommend just using the algorithm in our Casper FFG paper.”
You can read the whole exchange between Vitalik and Dan Larimer right here.
So, there you have it. In these two parts hopefully, you can get a gist of everything that is going to come along with EOSIO. Before we finish things off here, it is prudent to address the elephant in the room.
Yes, the EOS launch has been ”not so smooth” so far. However, we can’t tell for sure how things are going to pan out. But for now, all that we can do is to tell you the different features and properties that EOSIO Dawn 4.0 can bring along with it.
We hope you got immense value from this read.