Page Comparison

The idea here is to enhance the chain plugin so that the upgrade of the FIO Core for getter modifications becomes easier.

Overview

A table will be added to state in the FIO Core which identify by name the getter calls that can be performed. FIO system contracts will be enhanced to provide actions permitting BPs to update this information on chain.

Modifications will be made to the FIO chain plugin to provide a pluggable model of software extensibility for the chain plugin. The chain plugin will allow new dlls to be deployed quickly and atomically to a location on disk. Configuration information will be added to the chain plugin (either on chain or on disk) to identify the plugins to load. The chain plugin will be enhanced to provide a callable “update me” routine in the chain plugin to reinit the chain plugin with the latest updates. The chain plugin will be enhanced to provide a new endpoint in the chain plugin that uses json for parameters that define the getter to call and its parameters.

Benefits

This might ease deployment of the FIO Core code, by modularizing the components used to update getter routines, and by making a hot deployment of updates.

Risks

This might complicate deployment of api nodes (more information to manage and mis-configure, we need a process of updating the config info to be designed which complicates governance as well)

integration complexity increases, because this interface uses a meta data based set of parameters which further complicates calling getters.

The idea here is to enhance the chain plugin so that the upgrade of the FIO Core for getter modifications becomes easier.

Overview

A table will be added to state in the FIO Core which identify by name the getter calls that can be performed, along with the specific logic that is to be executed by each getter. FIO system contracts will be enhanced to provide actions permitting BPs to update this information on chain.

Modifications will be made to the FIO chain plugin to provide a new endpoint in the chain plugin that uses json for parameters that define the getter to call and its parameters.

A script interpreter will be introduced into the FIO Core, which will interpret the specific logic of each getter and execute this logic as part of the call to the getter.

Benefits

This effort removes deployment of getters as a concern from the API node operators and integrators.

Risks

This effort introduces a script interpreter into the FIO code base that is of equal complexity to the contracts layer.

Complexity

This is a very complex project with security, maintenance, testing, deployment, and other impacts to the FIO protocol for development and operations.

EOSIO compatibility

This is a significant enhancement to the EOSIO set of capabilities, so we will need to coordinate this and message and manage and possibly integrate this into the EOSIO community.

The idea here is to make the deployment of getters to be “out of the hands of integrators” and “into the hands of the block producers”. in this model, the getters will be implemented in a set of getter specific contracts in the FIO protocol. Block producers will deploy updates as they do any contract modifications to FIO, via MSIG approval by a majority of the active BPs. All get routines will be ported into a set of contracts in the FIO protocol for use via signed contract calls.

Details –

We will design a set of getter contracts that will provide the “read portal” for the FIO protocol. We will add information into state regarding the getters that may be called. We will add a new action that provides users the ability to call a generic “read” action which will use json to identify what getter to call along with the necessary parameters.

Because this is a contract call, users will have to perform packaging of a signed transaction on the FIO protocol to call these getters. We may be able to limit this packaging to eliminate the need for private key signing. The core will be modified to “skip” adding these tx to the FIO block log (transaction logs). We will also mod the core to “skip” private key signing checks for the getter calls which are listed in the new state table. This alleviates the need to worry over account information for the getter calls (though other signed transaction details must be observed in the packaging of the call for the FIO chain).

 Benefits

this provides block producers the ability to control when where and how the chain is upgraded for all getters. this offloads the responsibility of upgrading the chain from integrators.

getters can be enhanced as fluidly as with any contract update to the FIO protocol

Risks

This effort introduces a set of getter actions which can bloat the contracts layer, and which require signing (but not the same signing as we use for other calls to the contracts).

Complexity

This is a very complex project with security, maintenance, testing, deployment, and other impacts to the FIO protocol for development and operations.

This effort increases integration complexity significantly, and will impact SDKs and all integrators of FIO.

EOSIO compatibility

This is a significant enhancement to the EOSIO set of capabilities, so we will need to coordinate this and message and manage and possibly integrate this into the EOSIO community.

This slightly different signing of the getter tx is cumbersome and confusing.

The idea here is to create a new application separate from the FIO Core which functions much like the chain plugin, but which leverages hot deployment capabilities mentioned above. we can consider to implement some smart upgrade capabilities (Think App Store or fully automatic style upgrades), by detaching this from the FIO Core, we can provide a get capability that is loosely coupled to the FIO Core and which has more options for upgrading.

This project is best summarized as “some form of item 2 above, but in a separate application from the FIO Core”

1. We can provide meta data based query and hot deployment of upgrade components.

2. this component can be run without an API node, but requires interface to an api node to query. this can be run from any device and becomes a building block for block explorers and other tools requiring business logic relating to all aspects of FIOs functions

Benefits --

loosely coupled from the FIO Core code, adds hot deployability and other features without impacting the core code of the FIO protocol.

Risks--

this causes duplication of getter logic (inside FIO Core and outside).

integrators still need to install and manage this new app much like they do the FIO Core, so this complicates deployment for integrators.

The idea here is to provide a history node integrated, offline relational database that will contain the near real time reflection of the FIO state within it. We might provide option 1 above as the front end providing getter capabilities to FIO. We might provide an integration of existing EOSIO componentry or other technology solution available in the crypto space which will provide this.

if an off the shelf solution is not used, An ID/key will need to be designed and defined to provide cryptographically protected proof of authenticity for records contained in state. (to provide proof of authenticity for off chain data)

Benefits --

This provides near real time update of state information off the chain in a relational structure which can be powerfully queried using relational database technology.

This provides the foundation for simplifying and downsizing the FIO on chain state model, which is a key objective as the FIO protocol matures.