ACI registry database - Githubissues

In order to verify code executed on a remote machine, we need to verify that the executable are correct first. Running code or even loading unverified bytes into memory is the most insecure thing you can possibly do to your computer. For the complexity of our data types popular serialization frameworks like proto and avro used for gRPC don't carry enough information (namely byte code and type hierarchy info) in order for us to verify that serialized info is actually what we think it is. We can make use of proto however as an intermediary data type which sends Kryo serialized bytes as a field. Or we could just use openAPI, doing the same. The most important thing is that we store all state channel ACIs in a database which can be used to verify executable logic and polymorphic type info. This can be done by storing kryo serialized rerpresentations in the table as well as keeping a Krypo serializer in memory. Modifying this Kryo Serializer without recompiling/restarting the network is something we will want to look into in the future. We should be able to actually re-compile on the fly and then update the db in the future, but for now its totally ok to just require redeploy for updates. We will improve this process over time.

The database and way we make queries is important too. We need to use Quill (or something like it) to allow queries to the db to be typed using the scala type system i.e. written in scala syntax. Thus we should probably stick with Doobie. We will be able to use it's context within our own Cell context for ensuring order of operations if/when looking up in the db (some nodes may have several state pipelines/data type lookups happenning on their node at once.) So starting by initializing Doobie's context, which we will want to share across all pipelines, is the way to go (this might actually simplify the process of combining all the current constellation node managers into a Context when we re-implement ConstellationNode)

Here's a simple schema for the "Application Chain Interface" or ACI that I've been talking about:

{

address: String
serializedBytes: Array[Byte]
originalFiles: String
jsonString: String (Or Obj, for readability) }

I'd just do a k, v or like simple table with those fields. That's enough to get the validation working, we'll want to add token econ data there as well later. originalFiles is the actual compile-able files them self, or rather some sort of intermediary data structure that makes verifying with a Kryo Registrar easier.

DOD) 1) ACI registry db 2) Validation flow: lookup from intermediate serialization format's bytes field into the ACI registry to load into memory 3) Test/demo sinking into a Cell that loads the bytes into some class after verifying via lookup in the registry. I think you have proto working already so lets start there with Mu

Constellation-Labs / constellation

ACI registry database #1434