/
Storage Discussion Meeting notes

Storage Discussion Meeting notes

Feb 07, 2018

Date

Attendees

Goals

  • Get clarity on the datatypes that are in the storage layer, Trie implementation, understand the application behind it.
  • Serialization of the byte arrays is responsibility of the client, is this a good idea.
  • Putting compiler objects in LMDB, is the storage layer expected to handle this?

Discussion items

TimeItemWhoNotes
10What needs to be stored?Henry Till
  • Need to store the blockdag under a hash.
    • Com Events
    • New contracts to deploy
    • New messages to send
    • Will the client ofthe storage layer be resposible for serializing and de-serializing whatever this block data is?  Mike - hope we use protobufs.
      • Henry agrees - Initial protobuf will be implemented.
    • Are you familiar with Cbor - Has an RFC - Envisioned to be serialization and schemaless - Mike prefers having a schema.
      • Mike -we will have a very well defined block format.
  • Next portion is the tuplespace
    • Need one for system contracts & one for blockchain contracts
    • One logical LMDB instance.  Notion of sub-databases (haven't dug into it that yet)
  • Namespaces -
    • Griff was working with prolog terms like what Special K was using. 
    • We will use Rholang AST instead of Prolog.  When we hit free variables we bind them in the other?
    • Is the query mechanism above the storage layer - Henry - 
      • Mike - this is something we need to work out. 
      • Just this week learned about table add and table get - so long as your channels are literals, it's fine because ou are not doing any binding.
      • We are not promising any thing reading to or writing from channel patterns, beyond just literals.   
      • Is this a Scala library that is imported into the Rholang stuff?
        • MIke - Yes - and statically linked in.
      • Tuplespace Rholang keys for the moment are just flat keys, later on we want to be able to do broadcast (unix select) that you are listening on multiple channels and the first result is the one you take.
      • What about Yaralsau's work?  His stuff is bolted on to the side of RHolang.  The idea was that you could specify a regex for some data, and if you send some data - it unifies with the first one and you connect.
        • We don't need this for Mercury.  We knew we would need this eventually.  We used this work to help him get familiar with Scala.  This work won't be part of the initial release.  It's an alternate unification model.
    • Most of the express paths are designed so that you easily get the prolog terms.  
    • Mike describes LADL and Behavioral types. 
  • Third is the tuplespace for the block chain
    • Do you want a different function call?  Mike - no - not needed.  Convenient for the system contracts to reach the channel in a consistent way.
    • Medha missed this part about the keys - Henry needs to fill in.



  • You won't be granted to use the system contracts by the storage level, All clients talking to storage are assumed to have the authority to do so.  OCaps will handle this.
  • Update the storage spec doc and come to some written consensus.  Flesh out what needs to be done.  

Action items