EOSForce Mainnet Upgrade Report

EOSForce

7 min readDec 24, 2018

Total Mainnet Transaction Count: 1,399,000 tx (a weekly increase of 29k)

Mainnt Account Count: 577,375 (a weekly increase of 299)

Mainnet Vote Count: 151,246,806 EOSC (94.37% of the total activated EOSC)

Total Activated Genesis EOSC: 160,275,621 EOSC (a weekly increase of 1,755,719)

Activated Genesis Account Count: 3170(a weekly increase of 434)

Unactivated EOSC Genesis Lockup

Nov 29, 2018, after multiple rounds of deliberations at Super Node routine meetings, the proposal of EOSForce Mainnet unactivated genesis account lockup plan, proposed by Super Nodes Awake, Jiqix, OU, and Walian, was passed at 20 yays, 2 nays and 1 abstain, reaching a 2/3 super majority for passage.

Dec 20, 2018, the 23 Super Nodes started the mainnet major upgrade, which includes the execution of the lockup plan of unactivated EOSC.

Proposals passed during the aforementioned meeting:

EOSForce Mainnet Major Upgrade

23 Super Nodes offically completed the EOSForce Mainnet Upgrade 06:00 GMT Dec 21, 2018 after 24 hours of execution. Transaction, voting and voting dividend claiming were suspended during the upgrade to ensure the successful completion of the update. The EOSForce Core team apologizes for any inconvenience caused during the update!

This major upgrade includes:

Deployment of the system contract to execute unactivate genesis tokens.
Improvement on the trans-fee resource model
Newly-launched RAM resource model

The mainnet performance is improved 50% after the upgrade with significantly improved security of the mainnet.

With regard to the Genesis Lockup plan, the remaining 20% of the EOSForce EOSC tokens can be activated using the genesis key pair mapped on June 3rd. The locked 80% tokens are locked using the EOSLock token as the Lockip proof.

Note: the 80% Lockup can be undone by a future Super Node proposal.

EOSForce Resource Model

Resource on EOSForce

Every executing transaction on EOSForce needs to be executed by a node on EOSForce network. Results from node execution need to be computed by actual physical machines. The resources needed for the computation are in 3 categories: CPU, NET and RAM. CPU is calculated by the time needed to settle the transaction by the node. RAM is calculated by the amount of data generated by the transaction. These data need to be stored in the node to be read by other contracts.

Because the computation and storage capacitity of the node machine is limited, the total resource on the EOSForce network for user usage is limited. In order for all users to be able to use the resources for transactions and to prevent malicious use of computing resources that would cause users unable to transact, we need a series of resource distribution protocols. This is the EOSForce Resource Model.

To address the series of issues that regularly occur on the EOS Mainnet (EMLG), EOSForce made modifications to EOS to establish a new set of resource models, ensuring that users are able to use the resources provided by the EOSForce network when needed and preventing wasteful and malicious resource usage given that resources are distributed justly.

The following is an introduction to such a resource model.

Distributing CPU & NET resources based on Transaction Fee

On EOSForce, users pay transaction fee for each of the actions they trigger on the network. This is similar to Ethereum. Every transaction fee provides a resource uplimit for CPU and NET usage. For network-original transactions such as transactions, account creation, permission update and other actions, fixed trans-fee model is used to optimize user experience. For user customed actions, the amount is set through BP multisignature. In default condition, for each 0.01 EOSC, action is given a 200 us CPU limit and 500 byte NET limit to optimize user experience. Developers need to set up transaction fee limit for actions in the contract they submitted, such that users do not need to set up trans-fee limit amount themselves. This incentivizes developers to optimize contract resource usage efficiency and user experience.

Procedure as followed:

cleost transfer eosforce test "5000.0000 EOS" "fo test"executed transaction: ed62211eda722230472d416a8e3c92ab3f950fe951bcd357f9fb217792dac936  152 bytes  213 us#         eosio <= eosio::onfee                 {"actor":"eosforce","fee":"0.0100 EOS","bpname":"biosbpb"}#         eosio <= eosio::transfer              {"from":"eosforce","to":"test","quantity":"5000.0000 EOS","memo":"fo test"}#      eosforce <= eosio::transfer              {"from":"eosforce","to":"test","quantity":"5000.0000 EOS","memo":"fo test"}#          test <= eosio::transfer              {"from":"eosforce","to":"test","quantity":"5000.0000 EOS","memo":"fo test"}

We used EOSForce account to transfer 500 EOSC to test account. This transaction only ran eosio::transfer action, so this action executed the corresponding eosio::onfeeaction to charge 0.01 EOSC from EOSForce account as trans-fee.

Note that eosio::transfer action triggers eosforce=<eosio::transfer and test< =eosio::transfer these two announcements. But these two accounts did not use the corresponding announcements, so only 1 action is executed.

EOSForce calculates the trans-fee for all actions in the transaction individually. The action also includes inline action.

As followed, the testc is contract account. When a transaction is received, it transacts to testa and testb accounts. A transaction is contructed here to transact to testc account:

cleost transfer eosforce testc "5.0000 EOS" "fo test"  executed transaction: 6339c73f167602607c8ee1a89a73e7f0171f375b39b361eb47047f0e4a48c69d  152 bytes  646 us#         eosio <= eosio::onfee                 {"actor":"eosforce","fee":"0.0100 EOS","bpname":"biosbpm"}#         eosio <= eosio::transfer              {"from":"eosforce","to":"testc","quantity":"5.0000 EOS","memo":"fo test"}#      eosforce <= eosio::transfer              {"from":"eosforce","to":"testc","quantity":"5.0000 EOS","memo":"fo test"}#         testc <= eosio::transfer              {"from":"eosforce","to":"testc","quantity":"5.0000 EOS","memo":"fo test"}>> apply testc eosio transfer#         eosio <= eosio::onfee                 {"actor":"eosforce","fee":"0.0100 EOS","bpname":"biosbpm"}#         eosio <= eosio::transfer              {"from":"testc","to":"testa","quantity":"5.0000 EOS","memo":"1;testa"}#         testc <= eosio::transfer              {"from":"testc","to":"testa","quantity":"5.0000 EOS","memo":"1;testa"}>> apply testc eosio transfer#         testa <= eosio::transfer              {"from":"testc","to":"testa","quantity":"5.0000 EOS","memo":"1;testa"}#         eosio <= eosio::onfee                 {"actor":"eosforce","fee":"0.0100 EOS","bpname":"biosbpm"}#         eosio <= eosio::transfer              {"from":"testc","to":"testb","quantity":"5.0000 EOS","memo":"1;testa"}#         testc <= eosio::transfer              {"from":"testc","to":"testb","quantity":"5.0000 EOS","memo":"1;testa"}>> apply testc eosio transfer#         testb <= eosio::transfer              {"from":"testc","to":"testb","quantity":"5.0000 EOS","memo":"1;testa"}warning: transaction executed locally, but may not be confirmed by the network yet         ]

In this process, EOSForce requires 0.01 EOSC trans-fee to transact to testc first. Then testc contract triggers 2 inline_action, transacting to testa and testb individually, charging 0.01 EOSC twice, making the total contract trans-fee 0.03 EOSC.

Rental-based RAM Resource Distribution

Different from CPU and NET, RAM uses a rental method, setting a RAM uplimit for an account based on the rental fee it pays on a account-unit basis. The rental fee is charged based on time to optimize user operation experience. This way most regular users do not need to worry about RAM. Usually, developers need to pay for rental fees for the RAM their DApp uses, including the RAM occupied by contracts and RAM data occured during execution.

So far we accomplished the functionality of rental fee payment through voting dividend. On EOSForce, users receive voting dividend by voting, and RAM rental fee is calculated based on time and volume. By charging rental fees on voting dividend, EOSForce do not need to pay for rentals manually and voting participation is increased for ecosystem growth.

The flow goes like this:

user →voting →voting dividend →resource rental payment →RAM allocation

To simplify computing expenses, system sets up the rental fee ratio of EOSC voted against RAM allocated. The default ratio is 10 EOSC voted for 1kb RAM usage allocation, that is per 10,000 EOSC voted, 1MB RAM can be used. BPs can reset this ratio through multisignature to lower the ratio when BP cost gets lower.

Command Line Use Intructions

Paying for RAM rental fees through voting dividend can be set through eosio:vote4ram and eosio::unfreezeram to set voting amount and unfreeze voted tokens. The command is similar to eosio::vote and eosio::unfreeze:

Usually a user has 8kb free allocation. This can be viewed by acquiring use info:

cleos get account testccreated: 2018-05-28T12:00:00.000permissions:      owner     1:    1 EOS65jXw13YBGKGbKiJsFiq2TmnnYsAuaKEomqxZwu2xSQsd15D8q        active     1:    1 EOS65jXw13YBGKGbKiJsFiq2TmnnYsAuaKEomqxZwu2xSQsd15D8qmemory:      quota:         8 KiB    used:      2.66 KiB  net bandwidth:      used:               unlimited     available:          unlimited     limit:              unlimitedcpu bandwidth:     used:               unlimited     available:          unlimited     limit:              unlimited

Every user has an 8kb allocation after registration. Note that some user info takes up 2.66kb.

Account testc votes 1000 EOSC to bisbpd to receive voting dividend:

cleos push action eosio vote4ram '{"voter":"testc","bpname":"biosbpd","stake":"1000.0000 EOS"}' -p testc

By acquiring user info the user’s RAM allocation can be viewed for the moment:

cleost get account testc
created: 2018-05-28T12:00:00.000
permissions: 
     owner     1:    1 EOS65jXw13YBGKGbKiJsFiq2TmnnYsAuaKEomqxZwu2xSQsd15D8q
        active     1:    1 EOS65jXw13YBGKGbKiJsFiq2TmnnYsAuaKEomqxZwu2xSQsd15D8q
memory: 
     quota:       108 KiB    used:      2.66 KiB  

net bandwidth: 
     used:               unlimited
     available:          unlimited     limit:              unlimited

cpu bandwidth:
     used:               unlimited
     available:          unlimited     limit:              unlimited

User’s rantal payment through voting dividend can be viewed through votes4ram under eosio:

cleos get table eosio testc votes4ram {  "rows": [{      "bpname": "biosbpd",      "staked": "1000.0000 EOS",      "voteage": 572500,      "voteage_update_height": 637,      "unstaking": "1500.0000 EOS",      "unstake_height": 560    }  ],  "more": false}

Account testc unvotes the 300 EOSC voted for biosbpd. resetting the voted amount to 700 EOSC (1000EOSC — 300EOSC=700EOSC):

cleos push action eosio vote4ram '{"voter":"testc","bpname":"biosbpd","stake":"700.0000 EOS"}' -p testc

RAM can be unfreezed through eosio::unfreezeram after the unfreeze time is passed:

cleos push action eosio unfreezeram '{"voter":"testc","bpname":"biosbpd"}' -p testc

To take a look at EOSForce code base, feel free to visit our Github!

EOSC Christmas Giveaway

EOSForce has launched its Christmas holiday gift for the EOSIO community!

By activated your EOSForce genesis account, you will get 200 EOSC activation reward!

By inviting other genesis holders to activate their accounts, you will get additional EOSC bonuses!

The reward pool has a 100,000 EOSC limit. Click the link here to get your holiday EOSC gift right now! https://explorer.eosforce.io/en_eos_invite.html

So far more than 20,000 EOSC has been claimed by the community in just 2 days!