Are 1-Token-1-Vote and Voting Dividends Necessary for a Public DPOS blockchain?

14 min readJan 15, 2019

Community governance is the fundamental of the fundamentals.

Foreword

In a rare series of history-breaking tweets and messages, CEO of Block.One, Brendan Blumer, has been making comments on voting-rewards-sharing and one-token-one-vote mechanisms in a variety of public channels, and even proposed to charge transfer fees.

Experienced users of EOS community will find there are many similarities between BB’s new scheme and the one has been adopted by the running EOSForce mainnet. EOSForce mainnet has been running for more than six months with the one-token-one-vote, voting-rewards-sharing and charging-transfer-fee features. We’ve been suggesting that Block.One adopt the same economic model, and many blockchain media such as EOS Weekly also strongly advocate the community to refer to the economic model of EOSForce for improvements.

So are one-token-one-vote and voting-rewards-sharing features necessary for a public DPOS blockchain? Can the resource model of charging transaction fee solve the congestion problem of current network? This paper mainly introduces the EOSForce community’s thoughts on the evolution of these three mechanisms since the EOSForce mainnet launched.

1. Why is Voting Reward Sharing mechanism necessary for DPOS?

1.1 Preventing double-spending

Double-spending has not been taken seriously for a long time, until ETC suffered the double-spending attack recently.

In DPOS consensus model, higher voter turnouts make the network more secure and the benefit of attacking networks lower. Voting-rewards-sharing mechanism can motivate more users to participate in community governance via voting, increase voter turnout, and reduce the benefit of attacking networks. Long-term observation results show that voting rewards and voter turnout are positively correlated. The turnout of EOSForce mainnet remains at 90% due to its voting-rewards-sharing feature. While the turnout of EMLG is around 40% because of the lack of rewards.

1.2 Fighting inflation of the blockchain

For DPOS, the mainnet launches after the tokens have been issued (premine), so the incentive for nodes and BPs relies on the annual inflation rate. The EOSForce mainnet users can get rewards by voting, therefore, no matter how high the annual inflation rate is, the increase is returned to the voting users in the same proportion. The users who suffer losses are those who do not vote to participate in community governance.

The increase part from EOSEMLG’s annual inflation of 5% are all given to the Block Producers (or BPs), the benefit users can get from the inflation is fee-free. But 90% of users will not pay more than 5% of their total tokens in a year. So if EOS does not adopt voting-rewards-sharing mechanism, the user assets will quickly depreciate.

2. Is 1-Token-1-Vote a Must?

One-token-30-votes needs to be corrected.

There is a key point of one-token-one-vote is the super privilege.

For a DPOS blockchain, whether there is a super privilege or not, two thirds of the nodes have the final say. So with the 1-token-30-votes and the super privilege, the chain directly changes from a public blockchain to a private blockchain controlled by the an interest alliance or “BP cartel”.

How powerful is the super privilege? In a public test on May 17, the private key of the super-privilege account was accidentally acquired by someone who issued over 100 billion tokens and voted to his own node, which led to our emergency shutdown of the testnet. So we removed the super privilege in genesis block for the subsequent launch of mainnet. But later in the process of updating, we found that super privilege could make updating system contracts very efficient. And given that we have a one-token-one-vote mechanism, there is no possibility of conspiracy for BPs since the mainnet was launched, so we recovered the super-privilege feature, but it takes effect only when more than 2/3 BPs make multi-signing, not controlled by a single node.

Monopoly brought by one-token-30-votes mechanism is the biggest harm to EOS community. The Chinese community such as EOS Cannon, EOS Gravity and HelloEOS, made a significant contribution to the community. Some centralized exchanges use users’ tokens to vote without authorization. In the logic of 1e-token-30-votes, the power of evil is magnified, so that nodes and BPs that have made great contributions to the community can be restrained by others to make their voices heard. The truth is very simple, becoming a BP requires the votes of the exchanges, if there is disagreement with the exchange, there is a risk that there will be no opportunity to participate in community governance. Of course, the only benefit of one-token-30-votes may be that it brought the community together to get mainnet launching and collectively repelled the EOSForce at that stage.

3. Thoughts on Design of Voting-Rewards-Sharing and 1-Token-1-Vote Mechanisms

EOSForce also took a lot of detours on the design of voting-rewards-sharing at the beginning, but the good thing is that one-token-one-vote mechanism played a role.

The first problem: At the beginning, we adopted another extreme which 100% opened the permission of BPs to pay rewards to voting users, resulting in competition between nodes becoming a competition of rewards. The community did not know how to exercise its rights, but only cared about which nodes pay higher voting rewards.

The second problem: the 23 nodes split the block-generating rewards equally, so the node with the highest number of votes made more contributions, but its income and the voting users’ income are even less.

The third problem: we wrongly underestimated the role of BP candidate. At the beginning, we thought that if more professional BPs could be offline after a DDOS attack, BP candidates might also be offline. So there was no need for BP candidates to get rewards. As a result, once a node falls out of the BPs sequence, all its votes will be revoked immediately. And the BPs will lose the competitive pressure from the BP candidates, leading to the stable ranking of the BPs within a period of time, and some BP candidates will then withdraw from the community.

Taken together, these three problems turn the reward what should have been used as an incentive into an electoral bribery. After making so many stupid mistakes, the one-token-one-vote and voting-rewards-sharing played a role. And after a series of discussions and votes, eventually a proposal condense the crystallization of the wisdom of the community. It solved the three problems at once, adjust the reward back into a proper incentive. This proposal includes the BP candidates can get rewards, rewards shared according to the weight of votes, 30% of the rewards will be paid to the BPs’ account at once, the rest 70% of the rewards will pay to the community users and BPs themselves with an allocation scheme made by the BPs.

The advantage is that the nodes have a fixed percentage of income, and they get rewards according to the proportion of votes obtained in the total votes. The more votes obtained, the higher rewards get. As for the voting users, they can vote for the nodes they support without worrying about the income loss due to nodes’ ranking out of the BPs list. As for BP candidates, they don’t need to worry about users withdrawing tickets due to low ranking, and can make contributions to the community reassuringly. However, it will strive to be a BP who is responsible for accounting of block generating, because the BP has 15% more reward than the BP candidate. The specific proposal was approved by more than 2/3 BPs’ votes, and the mainnet was upgraded according to it and keeps these features up to now:

(1) The nodes whose votes obtained are more than 0.5% of the total votes of current network are profitable nodes. Among these profitable nodes, there are BPs and BP candidates. The first 23 are BPs and the rest are BP candidates.

(2) All profitable nodes can obtain certain income, and all incomes are distributed according to the voting weight: (weight of each vote = the number of total votes of profitable nodes /the number of total votes of the whole network)

1. The profitable nodes will get their income when each block is generated.

2. Each profitable node gains income according to the voting weight (i.e. the proportion of votes obtained in the total votes of the current network).

3. 70% of the income of each node will go into its reward pool, and the node can freely adjust the reward-sharing ratio to voters.

4. For the BPs, 15% of the income will be credited to its account as basic salary, and 15% of the income will be credited to its account as block-generating reward.

5. For the BP candidates, 15% of the income will be credited to its account as basic salary, and 15% of the income will be credited to EOSForce Foundation account.

6. The part less than 0.0001 EOSC is omitted from all single income. In particular, if the total amount of a single income is less than 0.0001 EOSC, it will not be issued. When the block-generating reward is calculated, if the sum of this part is greater than 0.0001 EOSC, it will be credited to EOSForce Foundation account.

Note: For voters, only voting for the profitable node can get rewards.

4. What Can Block.One Learn from EOSForce’s Resource model?

4.1 Two serious problems that EOS EMLG’s current resource model encounters:

- Network congestion

The free charge of mortgage has brought a large number of “econnoisseur” (i.e. click farming), which has brought a lot of junk transactions to the chain, resulting in a sharp rise in node costs and the network becomes extremely congested.

- User operation threshold is too high

The few steps of a mortgage blocked 99 % of the beginners, which seriously affected the popularity of EOSIO.

4.2 How does EOSForce’s resource model solve the above problems?

In EOSForce, each transaction execution needs to be run in nodes of EOSForce network, which means it needs to be computed by the actual physical machine. The computing resources required are classified into three categories: CPU, NET and RAM. CPU is settled in terms of the time it takes the node to execute the transaction. NET is settled by the size of the transaction message. And RAM, meaning memory, is settled by the size of the data generated by the transaction. This data needs to be stored in the memory of the node for other contracts to read and write. Because the physical machine of the node has limited computing power and storage capacity, the resources available to users throughout the EOSForce network are also limited. In order to enable all users to use resources for transactions and prevent some users from abusing computing resources, a series of resource allocation rules need to be established, which is the resource model of EOSForce.

4.2.1: Pay fees to use of CPU and NET resources

In EOSForce, we require users to pay a fee for each action they trigger, in a similar way to Ethereum. It will provide a CPU and NET resources limit for the action. For system native action such as transfer, creating users and privilege updating, it is fixed fee and resource restrictions mechanism, which is easy to use. For the user-customized action, the conversion rate is set by BP through multi-signing. By default, each transaction of 0.01 EOSC, the action will be given a CPU usage limitation of 200 us and NET usage limitation of 500 bytes. For user convenience, developers need to set the handling fee amount for the action in the contract submitted by themselves, so that users do not need to set it. At the same time, developers are encouraged to optimize the use efficiency of contract resources and provide users with a better experience.

4.2.2 Each account has an 8kb free amount of RAM, and the voting rewards can be used to rent RAM

Unlike CPU and NET, RAM uses the lease method and it set the upper limit of the RAM that can be used by the account according to the rent paid by the account. The rent is charged according to the time. In order to facilitate the user’s operation, we have set a rent free amount of 8kb for each account at this stage, so for most ordinary users they do not need to care about RAM. Usually, developers need to pay rent for the RAM used by their DAPP, including the RAM occupied by the contract and the RAM data generated during the execution.

At present, we realize the function of paying the rent by voting rewards and the users can get rewards by voting in EOSForce, which forms a Token flow. And the RAM is also charged according to the time and amount of the rental. Paying rent through rewards, on the one hand, is convenient for users to operate and users do not need to pay rent and deposit frequently. On the other hand, it can improve the voter turnout and promote the healthy development of the blockchain ecosystem.

EOSBet team, the super DAPP on EOS, has proposed three solutions in the community. The first solution is to recommend the use of EOSForce and Telos.

5. What Problems Have Been Encountered in the Development of Blockchain Applications?

Even if the above problems are solved and better underlying infrastructure is provided, the problems encountered by developers of blockchain applications are still unprecedented:

First, developers still need to figure out what problem to solve. There is no living space if it cannot solve any problem, that is why the DAPP BETDICE is so short-lived and not helpful to EOS price. It’s hard to imagine an application scenario by sitting in an office, developers still need to know more about the historical solution of the problem to be solved. Is it necessary to use the blockchain technology?

Second, developers should be familiar with the public chain and blockchain technology. In other words, they should be familiar with the powerful tool of blockchain. Simply writing a smart contract doesn’t make for a great application like bitcoin. Developers have insufficient understanding of the public chain, resulting in no way to maximize the role of blockchain.

Moreover, many people regard decentralization as an end. But our goal is not decentralization. Decentralization is just our means. Through more or less decentralization to guarantee the fairness, security and cost reduction of the issues we have to solve. Decentralization is a means rather than an end.

What also needs to be improved is the developer’s understanding of the economic model. If you look at the whole economic model of bitcoin, it’s really great and elaborate, and it’s very ambitious, but today a lot of developers just use the feature of token rewards.

When we are developing blockchain applications today, there is a misconception that we follow the logic of the early rise of the Internet. We may think that the development of blockchain is the same as the Internet, from text to pictures to video, or from gambling and drugs. But what’s missing is that those are the problems that the centralized Internet is good at solving, not the problems that blockchain is good at solving. In the early days of the Internet, it did not prove much more efficient than traditional businesses. If Alibaba had challenged new retail directly in the first place, it would like throwing straws against the wind. Similarly, before the blockchain challenges the social and e-commerce business dominated by the Internet interest alliance, it should at least prove the security and trust-cost-reduction advantages brought by the blockchain in the field it is good at.

6. What is the Bottleneck of the Single-Chain Resource Model?

At present, there is no good parallel processing scheme in the entire blockchain field, and the average performance of the public chain depends on the performance of block-generating server with the lowest configuration. Limited by the physical characteristics of silicon, the computing power of a single server will not continue to increase as rapidly as it has in the past decade for a long time in the future (5–10 years). The current Internet computing is to expand the number of centralized servers to solve the problem of performance limitations.

For blockchain, it is difficult to solve performance problems at an acceptable cost if only the computing and services of multiple applications are stacked on a single server.

For EOSIO, there are three performance bottlenecks, CPU, NET and RAM. Even if the CPU can achieve dozens of performance improvements in parallel in the future, RAM will still be limited by a single server for a long time. The recent public-chain practices of Ethereum and EOSIO have shown that it is almost impossible to rely on a public chain to achieve high performance and high concurrency under the premise of guaranteeing decentralization in the short term.

Although we can foresee a decade later, thanks to the continued breakthrough of technology and algorithm optimization of the chain, the bottleneck of single-chain will be solved. But in the recent 5–10 years, we will hardly see this breakthrough. In the future, we must propose an effective solution on the eve of the blockchain application outbreak.

Based on the judgment of technology evolution in 5–10 years, a business scenario needs to be hosted by a single public chain, and even a business scenario needs to be solved by a multi-chain architecture. Our EOSForce multi-chain and cross-chain protocol is developed for these reasons.

In the case of the ENU community, the ENU network was launched to achieve UBI. A decentralized organization promotes the basic income of the whole people. Launching the public chain network alone can minimize the resource cost and flexibly utilize the various characteristics of the public chain. And our continuous iterative DPOS protocol will have very good underlying support for ENU network, allowing the entire community to focus on UBI application development and popularization.

7. What is Launching the Public Blockchain with Just One Click?

Based on this judgment, we plan to provide developers with a one-click launching public blockchain service in Q1 2019. Based on the EOSForce multi-chain and cross-chain protocol, we can not only meet the needs of developers with multiple consensus models, but also meet the need for data structure differentiation and functional diversification on other chains.

Two new resource models are supported in the latest version of the EOSForce multi-chain Protocol. One is EOSIO’s mortgage and leasing resource model and the other is a free resource model. When launching a public blockchain based on the EOSForce multi-chain protocol, developers can choose one from three models, the EOSForce fee model, the EMLG mortgage leasing model and a free resource model similar to the consortium blockchain. Many people of public blockchain community look down on the consortium blockchain, but the consortium blockchain is the fastest one to embrace the block chain technology, and also the fastest one to produce practical applications.

Ethereum makes issuing tokens a kind of inclusive right, and the EOSForce will make it easier to launch a public blockchain of diversified consensus, while making it convenient for multiple chains to interoperate.

8. What is the VISION of EOSForce Team?

The vision of EOSForce development team is to explore a more open crypto economy infrastructure in practice. We continue to develop multi-chain and cross-chain protocols based on EOSForce.io to promote the application of blockchain in various industries.

This means that whether it is POW or DPOS, or multiple resource model requirements in DPOS, we need to explore and develop. So we made a series of initiatives:

Launched EOSForce, an EOS parallel mainnet, and assumed responsibility for network upgrade and iteration

Publicly support the “competitor” ENU

EOS EMLG is also supported in the smart contracts tutorial

Support BCH to develop a peer-to-peer electronic cash system

Provide the service of one-click to launch public blockchain

Contact EOSForce

Twitter | English Telegram | Reddit | Github |Korean Telegram

EOSForce blockchain explorer: https://explorer.eosforce.io/#/en

Wallets
https://github.com/eosforce/wallet-desktop

EOSC token is distributed in accordance with the EOS genesis mapping. You can activate your EOSForce genesis account here.
Scatter 10 has minor compatibility issues with EOSForce blockchain. Join the Telegram Channel here: https://t.me/Scatter. Visit the Scatter website at: https://get-scatter.com/

Exchanges
Bitforex | Akdex.io