Overview

FIO Chain has implemented modifications of EOSIO in order to simplify the interaction with the chain, e.g. account creation and permissions. Since Mainnet a number potential improvements have been identified. The objective of this initiative is to evaluate and potentially implement these enhancements.

Tracking

Initiative

https://fioprotocol.atlassian.net/browse/WP-221

Dev Epic

https://fioprotocol.atlassian.net/browse/BD-3245

Specific improvements

Improvements

Support custom permissions in the SDK

Currently custom permissions are not supported in the SDK. As a result, if an account owner was to modify the permissions and then import the private key to a wallet, chances are that wallet would not be able to interact with the FIO Chain properly.

Implementation

• Modify SDK to:

  • Properly initialize account from loaded private key. Currently public key is hashed to account and that account is used as actor

    • Fetch permissions from chain using get_account

    • Use the returned permissions to properly determine what actor, permission, and signing key should be used to process transaction.

  • Allow the developer to specify separately:

    • The target account - will be used as the account which executes the action and will be inserted into actor field inside specific action call (data field) and authorization → actor of call

    • The target permission - will be used as the account which executes the action and will be inserted into authorization → permission of call

    • The signing key - will be used to specify which user’s private key needs to sign the call

Support alternate FIO Public Key for encryption of New Funds Request/Record OBT content blob

Certain content on FIO Chain, e.g. FIO Request details, are encrypted using Diffie-Hellman encryption scheme. This scheme requires private key of one party and a public key of another. Today the key used for encryption is the same key which is used for sending and receiving tokens and is obtained using get_pub_address.

An improvement has been suggested to have a separate key for receiving tokens and for encryption. This would allow for a different security scheme be applied to each key. In fact, the account owner may not even have access to a private key designated as the receiving key for tokens, e.g. it’s in cold storage, while they do need to have access to the private key in order to decrypt some FIO Chain data.

The primary difficulty with implementing this change, would be the coordination required to have integrators start using a different call to fetch the encryption call vs. the sending key.

Implementation

• Create a new FIP which will propose implement:

  • Addition of new field encryption key to each account

  • Addition of new action to modify encryption key

  • Addition of new getter to return encryption key for a FIO Address

  • Backwards compatibility process

Support sending of FIO Tokens to an account

FIO Chain does not support a EOSIO transfer action, which takes account name as payee, and in turn requires the use of trnsfiopubky action, which requires a FIO Public Key. If one wanted to send FIO Tokens to a specific account, there is currently no easy way to get the FIO Public Key which hashes down to the account name. The key could be fetched from fio.address->accountmap table, but it requires complex table query logic. A more user friendly approach would be to create a custom getter which returns FIO Public Key for supplied account name, if one exists on chain. An alternative could be to support tokens being sent to an account.

Implementation

• Create a new FIP which will propose and implement:

  • Addition of new getter to return FIO Public Key for an account name

Support ability to create an account with custom permissions

Because accounts on FIO Chain are created automatically when a new FIO Public Key is used, the newaccount action is not a supported. However, every time a new account is created is has the FIO Public Key which hashes down to the account name set as the active and owner permission. This may break some user flows which would want to create a new account with custom permissions in one action.

This enhancement would allow for new accounts to be created with custom permissions rather than standard permissions.

Here’s the original request from one of the integrators:

"We need the ability to create an account with a separate owner and active key. When creating accounts, we create the owner key and offer the backup sheet to safely store it - and then establish an active key locally on the device. The UX would break if we then had to create subsequent transactions to alter the permissions into this scheme and would also require the user paying fees."

Implementation

• Create a new FIP which will propose and implement:

  • Addition of new action to create an account with custom permissions. The action would carry a new fee.

Lift limit on number of public keys allowed in custom permissions

Currently, when setting custom permissions, only one FIO Public Key can be supplied. This restriction was put in place to avoid the confusion associated with the automatic account creation and the importance of FIO Public Key for sending and receiving tokens. In fact, it was envisioned that only a FIO Public key which hashes down to the account name can be entered, although that restriction was not implemented, due to time-to-market priority.

This enhancement would allow for any number of FIO Public Keys to be supplied in custom permissions.

Here’s the original request from one of the integrators:

"We need multiple active keys in our current configuration. Our account recovery process revolves around two options during recovery: first the ability to remove all active keys and set a new one (establish a new sole device), and the second being to add a new active key (which allows the addition of a new device)."

Implementation

• Create a new FIP which will propose and implement:

  • Removal of the restriction which only allows one FIO Public Key in updateauth

Extend permissions to custom FIO actions

Currently it’s not possible to allow a different account to execute FIO Chain actions which are restricted to specific account. For example, FIO Chain allows only FIO Domain owner to register FIO Addresses on that domain and there is no way to create a custom permission which would allow another account to do it, assuming you: a) want to allow only a specific domain and not all domains that account owns; or b) you want the registering account to pay the registration fee.

This enhancement would extend the FIO Chain permission scheme to enable granting of permissions in those cases.

Implementation

• Add specific calls to allow domain owner to set address registration permissions on specific domain