Purpose:
The purpose of this document is to communicate various details associated with the https://fioprotocol.atlassian.net/browse/BD-2041 story. This document will list the various end points necessary to achieve this approach, along with various interaction diagrams intended to illustrate the approach.
Overview --
This approach has been created to increase the level of security for read operations within the FIO Protocol. Presently the protocol is vulnerable to man in the middle attacks. The man in the middle could intercept any requests to API nodes (by taking over the API node, or by intercepting the traffic to the api node on the network) the man in the middle could inject any data desirable (funds request public address info, or pub address info for fio address mappings) to redirect funds to the hackers desired addresses, thus stealing funds.
...
We will next describe the FIO state tables, API endpoints, and wallet based structures required to implement this approach.
Added State tables --
producers – add the apinode attribute. this will permit bps to record the url of the api node they are running
...
get_producer_changes – this history endpoint will return a list of block producer schedule changes that occurred after the specified block number, the block number, api node url, and pub key of the new producers, associated with each block producer schedule change will be returned..
API Endpoints --
Register_BP_API_url – This request will be signed by the BP account, it will set the apiurl attribute on the producer_info record associated with this producer in the producers table.
Contract actions –
regapi – a new action permitting BPs to register the API node url they want users to use.
History changes --
The FIO history node will be modified to build and maintain an index of BP schedule changes, it will capture the schedule changes and also the block numbers BP pub key, and api node url, associated with these changes (it might also be useful to capture the block info for these schedule changes to save a call for clients performing validations).wallets
Client Considerations--
Clients will invoke a new endpoint on the FIO history node to get_producer_schedule_changes.
wallets Clients will then get the list of blocks from this call and they will validate cryptographically that the block is valid using a process similar to this:
...
https://steemit.com/eos/@dan/inter-blockchain-communication-via-merkle-proofs-with-eos-io, but in contrast it seems that this is a problem for IBC, essentially having the same underlying needs for lightweight verification, eosSweden mentions it here: https://medium.com/@eosswedenorg/provide-up-to-date-snapshots-to-support-ibc-and-history-nodes-3b8f7160f1b8
the wallet The client will verify the block then use the schedule to update the list of BPs they will use for interactions with the API nodes.
The wallet will then use this query thequery strategy indicated above in “querying the FIO Protocol” to query information that is deemed sensitive for the FIO Protocol (get pub address, get FIO requests).
...