Interfacing Comms, Storage, and Rholang Meeting notes

Owned by Medha Parlikar (Unlicensed)
Last updated: Mar 13, 2018 by Henry Till

Date

Attendees

Goals

  • Get on the same page on what is needed for the April release.
  • Discuss at a high level what needs to be done in order to support message passing via Rholang
    • Do all messages to and from the Communications module go through the tuplespace? - Are there any exceptions to this? -
    • What is the format of these messages?
    • Are there any messages that we can see that would use the data structures implemented for Rholang (Rholang ADT & Kent's protos) that would ultimately wind up in communications?
    • Do we have a Protobuf primitive in Rholang?

Discussion items

TimeItemWhoNotes
Overview
  • Where does Comms fit in?  Does it fit into the Rholang interpreter?
  • There have to be portions of the communications below the VM.
    • Rholang makes assumptions about connectivity that are not aligned with the realities of the internet.  It expects messages to be reliable.
    • Rholang doesn't have abstractions for message delivery failure.
    • We want the VM to eat its own dogfood as much as possible.  Implement as much as we can in Rholang?  How realistic is this for Mercury? Good topic to discuss.

 Where does Comms Fit in?
  • Comms has 2 types of communication.  Node to Node (used by CASPER) and Node to Blockchain (Node proposes a new block)
  • We don't know what the message format is specifically as yet.

Where does the Tuplespace fit in?Michael Stay (Unlicensed)
  • Below Tuplespace, build in Comm libraries.  Rholang code to talk to comms via the Tuplespace.  Tuplespace implements system processes.  Easy for Henry to see the send side, harder to see the receive side.
    • See the networking layer the same as the Interpreter, it will receive from the tuplespace by receiving, but it will also send messages.  It would have the produce and consume verbs available to it as well.
    • Providing Produce and Consume to N clients - Design questions
      • Simple as pointing LMDB to the same db files? Do we need to build in multi-client access for the storage layer.
      • Currently, storage only supports a single client.
    • Per Kyle, A system process never hits LMDB, it remains in the in-memory portion of the tuplespace. 
    • Using LMDB transactions to implement 'concurrency' - no threading model in place.
    • Single instance of storage, handed to the interpreter, and handed to the comms layer.  They both get the same instance.
      • Comms can't start up until storage is on line.
      • Node code is what instantiates storage & the interpreter.  

Is it written in Scala?Henry Till
  • Everything with the exception of the system.channel will be authored in Scala.

Handling failure?
  • Communications Failures will be handled below the tuplespace.  Errors will be passed to an Error channel in the Tuplespace.

Sending Rholang Terms
  • Normal form is a protobuf.  Do we use this format for all data, including simple data? Or do we use a separate data structure by building a protobuf, by create a method to create a protobuf (Protobuf Rholang primitive)

Communications stack & messages
  • Protobuf and RPC.  
  • 1 common RPC protocol 

Node.03 April Milestone

A node user (at a "sending" node) should be to create a smart contract that creates some trivial message (e.g. "Hello, world!"), produce this message on a system channel with a specified destination channel. 

A system process at the aforementioned channel will serialize the message and pass it to the comms layer.

The comms layer of the "sending" node will sign/encrypt the message and send it out over network. 

Other "receiving" nodes will receive the message, and if they are running a smart contract that is consumes from the destination channel with a matching pattern, the message will appear in the match bindings. 

The receiving node should then be able to produce the message on the STDOUT system channel, effectively printing that message to STDOUT.

Action items