Project Planning Jan 25, 2018

• Quick status update on release
• Kyle has one more fix to implement.
• Kyle's PR needs to be merged.
• Mike will test the example contracts & tutorial after Kyle's fix is in.
• Medha to get an updated status tomorrow morning.

Status update from last week on:

• Chris can start out with communications stuff, and as more things become more accessible, we can roll more in. 
• Chris will resurrect his old code and start building out the front of the node. 
• Websocket interfaces for logging.
• Document needs fleshing out for the different components (JSON API (RPC and Websocket))

• Update after meetings with folks on Storage and Tuplespace
  • How does storage interact with multple VM's / Nodes in the future,  1:1 or 1: Many
    • Need to dedicate 1 thread  / queue (containing context)  is the way to go.  Timm is not sure that this would work.  Synchronization would happen via com events.
    • The transition function is completely re-entrant - that is Mike's understanding.  If it isn't we need to figure out what it is. 
    • How does the node come together?  Primitives or Node Code that wraps it up.  Notes from meeting below:
    • Node code would start up the comms and storage and pass these to the VM?  Seems reasonable? For example, upon startup, the VM was passed the location of storage, and the VM nows know about where it can be accessed.
    • Mike thinks that Nodes should manage collections of VM's - deploying contracts, managing VM's, requesting a name to be registered.  The individual VM's would then create storage objects if they need them.
    • Use a FFI or primitives - VM would be responsible for hooking itself up to storage?
    • replace table_add and table_get with a call that works with LMDB
  • What is the decision on rollbacks?
    • Option 1: At finality snapshot the VM state. In the event of a rollback, roll back the state to the last finalized block, and replay the Com events in the block to achieve updated VM state.
    • Option 2: Implement a serialization mechanism that is delta based to store the machine state and snapshot every so often.  Rollback based on the deltas.
    • Option 3: Compute state for every block in advance and remember it in case that block wins.
  • Set aside a set of channels that are only used for blockchain, so that sending on that channel, will result in persisting the state of the vm on the channel
  • We will need storage for the blocks in the dag implemented as a trie. 
  • Storage needs to provide API calls for put and get, which persist and retrieve in data in a LMDB-backed trie.

• Are we going to implement a Foreign Function interface for the VM?
• Proposal from Mike:
• new fsRet in {
    system!("getFs", fsRet) |
    for (fs <- fsRet) {
      fs!("link", "MyJar.jar", "MyClass", myClassCtorRet) |
      for (myClassCtor <- myClassCtorRet) new myClassInstanceRet in {
        myClassCtor!(arg1, ..., argn, myClassInstanceRet) |
        for (myClassInstance <- myClassInstanceRet) new ret in {
          myClassInstance!("method", arg1, ..., argn, ret) |
          for (val <- ret) {
            // do something with val, etc.
• Mike's opinion is that we should at the node level (not blockchain accessible) 
• Chris: in order for Rholang to be usable independent of the blockchain, it will need one.  But the node doesn't actually need one, considering the node code.
• Ex: Crypto - for Iran - version of Node without Crypto, plug in Crypto.
• Henry -what is the node code? - Powerbox contracts that wraps up the node level resources.  Enables the system contracts to do I/O - and has to be wrapped up so Rholang can use these resources as channels.
• Who will build the FFI, how long will it take.  Mike - Part of Roscala, involve collaboration between VM team & storage team.  Will need to be written in Scala, and possibly some RBL.
• Expose the FFI as a primitive in RBL that does something - then we can wrap it up as an actor.  Provide some Scala code that provides a Jar somehow, and then RBL code that wraps those primitives.

• What comes after Node.Hello:  Node API for Communications

• Node.Void→ Node Application Layer & Start of Node API→ Mid March (Chris is out next week) 

  • Start and Stop the VM
  • Start and Stop comms library
  • Run VM OpCodes
  • View VM Output
  • Tail Logs
  • Start and stop emitting metrics
• April: Can we look at adding RBL CASPER into the node, this gives Chris requirements for Communications.  Depends on RBL Compiler.  CASPER will also require primitives be implemented.

From Last week:

• Can we write a primitive to send a message across the comms layer - and could the VM execute it - As soon as Transition is done, we could do something.  Possibly done by end by March.
• Up next VM into the Node - write programs using opcodes that does something interesting and demonstrates the use of the comms and storage layer.  
• Implement more Primitives - If we have primitives that can be invoked using ApplyPrim() - we can demonstrate many primitives even without boot.rbl.