Minimize code deviation from EOSIO

[ericbutz]

Creating an issue to track the ongoing discussions regarding FIO code deviations from EOSIO.

[cc32d9]

I would propose a 2-phase plan:

Phase 1. Isolated FIO API

remove /v1/chain from user interaction, and define an API that completely covers everything an end-user application needs to use. Ideally, start a fio_api_plugin which would open its own HTTP socket and implement the API independently from EOSIO API.

Methods that require sending a transaction could be implemented as follows:

1. User calls an unauthenticated API method, like /fio/transfer_fio.

2. The server prepares an EOSIO transaction and sends a binary blob back to the user for signing.

3. The user calls /fio/push_transaction with the signed blob.

So, all user-facing smart contract actions can be encapsulated in such an API. Also this plugin would provide all informational requests, such as searching for a domain, displaying fees, looking up the user balance.

Phase 2. Migrate to vanilla EOSIO

This requires significant efforts, and potentially a relaunch of the FIO blockchain. The goal is to have the original nodeos code as delivered by Block.one and have all FIO specifics isolated in a plugin.

Also as many customizations as possible, such as permissions management, should be moved from nodeos code into the system smart contract.

In this case, fio_api_plugin would also perform public key format conversion to keep the backward compatibility with "FIOxxx" keys.

The native EOSIO API doesn't even need to be exposed to the public. It would only be used for internal infrastructure at BP and application service providers.

---

If Phase 1 is started ASAP, it will guarantee long-term compatibility for user-facing software, and will allow for a thorough and careful implementation of Phase 2.

[aaroncox]

Regarding Phase 1: removing access to the native /v1/chain/ API endpoints would break any cross compatibility we already have with existing generic EOSIO tooling (such as eosjs). This change would be a bit extreme.

Instead I'd just recommend leaving the /v1/chain plugin and APIs alone completely while still allowing access to them when needed. Any modified or additional API calls that need to be established for FIO can be put in the fio_api_plugin as described, which can coexist with the native API calls.

[cc32d9]

Phase 1 can be introduced smoothly, in sub-phases:

1.1 introduce the new API and keep the old one

1.2 phase out the old API

1.3 cut the old API from public access

[lukestokes]

while still allowing access to them when needed

I'm still fuzzy on how v1 calls can remain unchanged without deeper integration into the consensus logic of the chain (fees, error responses, etc), but that's probably due to my lack of understanding. The fees are what protect the chain and no call on chain can be free.

[lukestokes]

Adding some links here regarding wrapping eosjs and this example of how it might be done.

[cc32d9]

while still allowing access to them when needed

I'm still fuzzy on how v1 calls can remain unchanged without deeper integration into the consensus logic of the chain (fees, error responses, etc), but that's probably due to my lack of understanding. The fees are what protect the chain and no call on chain can be free.

see here, for example. max_fee is the action argument that is passed along other arguments. So it's not a change in the base transaction protocol:

https://github.com/fioprotocol/fio/blob/master/fio.contracts/contracts/fio.address/fio.address.cpp#L413

[ericbutz]

Tracked in: https://fioprotocol.atlassian.net/browse/BD-1905