Brainstorming FIO off chain state with EOS Amsterdam.

Zoom Meeting with EOS Amsterdam

Attendees:

Stan

Ed

Eric

Date/time : 1/25/2022 11:30a MST

Agenda :

    Review the history and background associated with the database creation script submitted on the FIO main net channel by EOS Amsterdam. Also discuss various data logistics and available technologies surrounding off chain state database capture, and administration.

Meeting notes:

   We discussed the history background and purpose of Stans light API for FIO. We discussed some possible paths for the FIO off chain state

   Light API for FIO provides a database, data management tools, and population technology from the history plugin.

   The FIO light API database is manually created, by going through state manually and creating the SQL to create the database, the data gets taken from state history plugin.

   A string of json comes out of state history, and light API for FIO provides lots of scripts and tools for processing the data.

   There is a tool that will parse the ABI and populate a database, which can then be used for any purposes we might have. (so there is componentry to capture the structure of FIO state on an as needed basis for various purposes)

   Defuse —

       Eosnation — supports them.   Plugin that exports table deltas, and can be indexed.

       State history is good cuz it does an archive file you can read at your own pace or parallelize. Defuse kind of blocks and holds up processing. Where the archive file processing does not do this.

    Biggest challenge of this effort is validity of the data stored in the off chain database.

     Demux is kind of stalled somehow — earlier version of demux was reading blocks, they added state history processing but its nobody’s child, and and has not been updated in a long while, its a project kind of not owned by anyone. There is Hyperion, and a database reflecting NFT history, in a Postgres database.

  Q: How did these efforts do data validation?

A: There is no level of verification of authenticity, but there is a smart contract that is the source of truth, and for FIO its slightly different. We need to validate the authenticity of this off chain data as part of this off chain state database project.

2 problems we have with FIO off chain state 1 we must verify the data is identical to whats in state, 2 we may need an authorization model to permit update of supplemental data associated with state data.

We can use a hashed ID (expensive computationally) or we can use a Merkle tree to provide the proof of state authenticity for the off chain data.

    This Merkle tree can be used to help to solve the issue stan brought up earlier in the project, the exposure to the man in the middle attack.

   We need to have some kind of Merkle tree.

   The client (anyone) needs to have a quick way to verify that the data they are using is authentic.

   Merkle trees,

We can ask Todd Flemming to do an enhancement to the state history, wouldn’t it be nice if state history could be self verifiable, this adds volume and size.

   There could be one hash per block, small in size, and maybe this could be done.

   Talk to todd flemming.