The team at ForceUSA looked into the EOS Force protocol and found that it had made several improvement to the original EOS.io system. These are the main differences:
Supporting distribution of dividends for voters
- Original EOS protocol pledges 1% bonus to all supernodes but strictly forbids distribution of any bonuses to any other voters. This disincentivizes participation in voting for other community members thus inhibiting a more diversified voter profile and increases the chances of a few supernodes collating forces to manipulate votes. This greatly increases security risks of the network as a few powerful supernodes might initiate a fork.
- EOS FORCE mints three new tokens every second, with yearly increase in supply totaling to an amount of 94608000 EOS FORCE tokens as rewards. Supernodes are able to freely adjust their commission rate, for instance, they can indicate a commission of 1%. Once they are elected and produced a block, each block producer is entitled to 1% of all block rewards distributed and the remaining 99% will be credited to a reward pool. After which, a rating will be given to all community voters based on their voting stake and time of voting and they will be each be entitled to a certain percentage of the reward pool as bonus. Community voters are able to withdraw their entitled bonus anytime. After every withdrawal, their rating will be adjusted back to zero and calculations will restart.
- If the network has pledged 300 million EOS FORCE tokens to participate in voting, all voters will have an equal share of the 94608000 EOS FORCE tokens, with annualized returns equivalent to 30%. Annualized return for individual community member will decrease as voting participation rate increases. As the total supply of tokens increases yearly, the rewards allocation will also decreases correspondingly.
- Community bonuses on EOS FORCE mainnet will require manual withdrawal from the members themselves. This is to reduce the occurrence of automated high volume, small amount transactions which adds burden to the calculation resources on the network. Bonus amount will not be affected by the sequence of withdrawal. All withdrawn bonuses will be included as part of the spendable balance.
- For users who have voted for a node that has yet to be elected as a block producer, their votes will be recorded and accumulated overtime. When the node that they have voted for gets elected, they will be entitled to bonuses from the reward pools with other voters.
One vote to one node
- The original EOS protocol implements 30 Approval votes for Block Producers (BPs) and specify users to pledge a deposit (such as 1,000 EOS) for staking purposes before they can pledge their votes. This can result in coalition in forces within supernodes and they can arrange to manipulate the system by voting for each other. Once 21 of the nodes form an alliance and vote for each other, it is almost impossible for other nodes to participate in the voting process. This will challenge the decentralization of the voting process and increase the risk of the network being controlled by these alliances. Users are also unable to pledge different number of votes to different nodes based on the level of trust they have.
- EOS FORCE wishes to amend voting rules to ‘one vote to one block producer’ and one EOS FORCE token is used to stake for one vote and they are allowed to place different number of votes for different nodes. For instance, if I had 1000 EOS, I can stake 300 EOS to vote for node A, whose commission is 1% and I can stake 100 EOS to vote for node B, whose commission is 1.5%. I will have a balance of 600 EOS and be rewarded bonuses if either of these nodes get elected as a supernode.
- Users can also adjust their number of votes, either by increasing or reducing the number of their votes. If they wish to increase their votes, it will automatically trigger a withdrawal of their entitled reward from the reward pool and tokens will be deducted from their balance for staking purposes. If they wish to reduce their vote, it will also automatically trigger a withdrawal of their entitled reward from the reward pool and tokens the user should receive from the reduced stakes will be frozen for three days. Users will then have to manually ‘unfreeze’ the tokens and credit them to their balances.
High stability
- The original EOS protocol allows one block creation every 0.5 seconds and one node to produce 12 blocks consecutively. However, such speeds are not validated among the existing global distributed networks and therefore, any delay within the global networks will result in a fork and cessation of chain continuation.
- EOS FORCE has made some amendments: three seconds for one block creation and one node to produce one block at one time. The core function of the network upon mainnet launch is not speed, but stability. Once the network stablises, and the nodes are capable of producing blocks fast enough, we will then resume the speed of creating one block every 0.5 second.
- As mentioned, our main focus upon mainnet launch is stability, hence the network will only enable certain functions such as transfer of ledger balance, voting, adjusting of bonuses. Smart contract deployment will be temporarily unavailable. Once the basic functions of the network are stable, we will then allow deployment of smart contracts on the mainnet and allow developers to develop DAPPs.
Transaction fees
- The original EOS protocol requires users to pledge EOS tokens as deposit for every transaction to increase competitive uses of the blockchain and achieve zero transaction fees. However, we users do not notice the hidden fees involved in such design of mechanisms. As mentioned, supernodes receive 1% bonus every year and this results in a yearly 1% inflation of the token value that users have to bear — unknowingly. For users who hold very little EOS tokens, they are unable to compete with users who hold large amount of EOS tokens who can pledge a large amount as deposit for every transaction. The lack of effective resource management and design of token transfer, greatly reduces this specific functionality of EOS protocol.
- EOS FORCE implemented transaction fees to reduce the risk of the network to be under DDOS attack. Transaction fees need not be set by the users themselves and will automatically be deducted from their balance. As users who hold small amount of EOS tokens are now able to perform transactions such as voting, they are now entitled to future possible bonus allocation when the node they voted for gets elected. Therefore, it is still beneficial to the entire community at large.
There are now 23 supernodes
- The original EOS protocol has set the number of supernodes to be 21, which is a multiple of 3, that is not ideal for mechanism designed
1. rejection if more than 1/3 of the votes garnered and,
2. approval if more than 2/3 of the votes garnered.
- EOS FORCE amended the number to supernodes to be 23, which allow for 8 votes for a proposal to be rejected and 16 votes for a proposal to be approved. These two numbers will also be used to confirm the immutability of blocks.
- The genesis block of EOS FORCE by default will have 23 nodes, and will be allocated to pre-selected technical partners for mainnet launch. They are unable to accept votes from community members and those who wish to be elected as a supernode will have to register and garner votes for themselves. Votes will be tabulated everyday and the node with the highest vote for the day will replace one of the pre-selected nodes and this process of replacing all pre-selected nodes will be completed in 23 days.
Smart contract update
- The rules of governance defined in the original protocol is incomplete and the amendments to rules, smart contract governance and changing of private keys as mentioned in the latest whitepaper have yet to be fully developed.
- EOS FORCE has completed development of a simplified version of the system smart contract update, and therefore is able to implement changes to smart contract and its parameters based on voting.
Mapping of default username set by users
- The smart contract by EOS only provided mapping for EOS public keys and users will have to manually reset their usernames during activation. Users are only allowed to perform on-chain transactions using their usernames, and resetting their usernames will cost mapping users transaction fees.
- EOS FORCE will generate usernames for users during genesis block creation, using the last 12 characters of their public keys, with all alphabets to be small lettered, numbers larger than five to be subtracted by five. This reduces the hassle of having to reset their usernames and they can perform any on-chain transactions by just inputting their private keys.
Why a layered architecture:
- Compared with the EOSIO blockchain, the layered architecture has the following advantages.
Based on the simplified version of EOSIO technology, the settlement layer main chain can achieve 10 times the performance of EOSIO. If EOSIO will reach its original vision of one million of TPS, then the settlement layer will be able to reach millions of TPS. Each application layer chain can also maintain one million of TPS and all of them can have their own constitutional rules, resource issuance rules, etc. The settlement layer undertakes the initial issuance financing and large-value bookkeeping work of tokens on the computing layer chains. The application layer can use various DAPPs to perform the cross-chain transfer. The settlement layer is similar to the core system of a bank that is only responsible for asset bookkeeping and accounting, and sidechains are similar to e-commerce system outside the bank.
