FIO vs. EOSIO

Owned by Eric Butz
Last updated: May 25, 2022 by Adam Androulidakis
3 min read

Accounts

FIO accounts are automatically created by the API when transfer trnsfiopubky and regaddress are called. New accounts are all created with limited RAM. RAM limits are increased as users pay fees.

A FIO account is a hash of the FIO public key. The protocol keeps a map of the single pub key associated with each account in state. For signing, wallets include the actor in the signed content, and signed API calls require the actor parameter.

On contracts, the key conversion is done by key_to_account method of fio.common/keyops.hpp
https://github.com/fioprotocol/fio.contracts/blob/master/contracts/fio.common/keyops.hpp#L91

Application in trnsfiopubky

https://github.com/fioprotocol/fio.contracts/blob/master/contracts/fio.token/src/fio.token.cpp#L275

 

Action filtering

FIO does not permit any contracts to be deployed by users. FIO is a single Dapp. Similar to EOSIO, any system contract updates must be agreed to by 2/3 + 1 of the block producers. FIO makes use of action filtering as an additional security measure to prevent unauthorized actions from ever being executed.

Relevant modified core code:

https://github.com/fioprotocol/fio/blob/master/libraries/chain/apply_context.cpp#L68-L78

addaction and remaction actions are used by the block producers to indicate which contracts and actions can be executed. They are overloaded in the fio.system.cpp contract implementation.


Disabling of resource staking

Code for pertaining to staking the system token and resource tokens such as EOS (FIO), CPU and NET have been removed from the codebase to support FIO. RAM exchange (REX) has also been removed.

User resources and limits

As mentioned previously, system resources are allocated automatically for the users at account creation. The original account creation method from eosio.system contract has been heavily modified here

Every user has unlimited CPU and NET but there are maximums in place restricting potential bloating of the block log, cpu and net utilization.

The original default_max_transaction_cpu_usage statement has been lowered to be 50’000 micro from 66’666.67 microseconds

Since users cannot deploy contracts, this maximum cpu execution limit is the only one enforced on contracts and each contract that exists on the chain is thoroughly audited so that there is no possible scenario that would allow a single action to create runaway/unlimited CPU execution.

Every user authorized action has a maximum potential size. Transactions that are too large will be rejected. If an actions size is not restricted by this method, it is by default restricted by default_max_transaction_net_usage.


Fees

FIO does not require staking of tokens to execute transactions. All operations on the FIO protocol have an associated fee, which is collected from user. FIO also has the notion of a bundled transactions: a number of transactions of certain type that are included with every FIO Crypto Handle. Other calls have mandatory fees. Fees are set through votes of the block producers. Each fee is represented in state in the fees table.


There are three different inline actions executed on various types of actions for distributing fees to the foundation, tpid and block producers:

process rewards, process bucket rewards, and process rewards no tpid

Technology Providers

FIO has the notion of a TPID (Technology Provider ID). It is a FIO Crypto Handle created by the integrator. If the TPID is included in the API call then part of the fees of that call will go to the specified TPID.

The TPID is automatically created if an action is supplied with a valid FIO Handle under the TPID parameter. It is important to note that with an invalid TPID specified, actions will still execute anyway and a TPID will not collect a portion of the fee.

Token contract

The original eosio.token transfer function is not supported for users. The action is reserved for block producers and inline actions for that perform internal accounting within the FIO system contracts. trnsfiopubky is the action for general users transferring tokens. At this time users cannot create fungible tokens on the FIO blockchain.

Chain Plugin

The chain_plugin and chain_api_plugin have been modified to support more extensive getter functions to walk the state tables for specific information. Otherwise, get_table_rows can still be used for all lookups.

Http_plugin

The http_plugin has been modified to support more detailed error responses within the FIO contracts. The expected error responses for various actions are detailed in the FIP specifications.
See added function httpify_exception and updates to handle_exception

Contract support functionality for FIO 400, 403 and 404 exceptions is implemented in fio.common/fioerror.hpp