Node Integration Meeting notes

 - The VM can have OpCodes, but without the compiler, it cannot run the OpCodes.

• How will the VM have access to the communications layer?  there are 2 different ways that the VM needs networking stuff.
  • We want primitives that produce and operate on sockets.  Put stuff in and take stuff out of the socket.  None of that is hard, not related to the comms layer.
  • The other part is fuzzier to Chris - there is a notion that a communication has happened in the network - and that communication has to bubble up to the VM
  • An event has happened, a name channel has input on it, and is ready to be consumed by the VM.  In the same way that normal channels in the VM has input in them that is ready to be consumed.  
  • Communications layer will see all the names that the VM has access to & will have to monitor chatter FOR those names.  
  • There would be a table of names that had been registered, that would be shared between the VM and the communications layer.  The names mean different things to the VM and Comms layer. Example for the Comms layer, the names would map to sockets. For the VM these names would map to channels. 
  • Question  -where would this table be stored?  Storage? Seems reasonable, this would be persistent.  
    • If a contract is expecting input on some name, and that name is a network channel, and the input goes into storage, then the comms layer could interact with the storage to stick the input in the storage layer
    • Where does the input sit while it is waiting to be processed?  I have a contract that is waiting for input (a continuation) - The system receives a message on a channel from the network (ex: Oracle), where is the message stored until it is processed?
    • The VM has a scheduler -  It uses cooperative multitasking, like Windows 95. Any time it's about to do a function call or return from one, it creates a new context, pushes it onto the task queue, and yields. Once that context comes to the head of the queue, it's allowed to proceed.
    • Communications between contracts do not go through the network outside of the blockchain.  
    • Communications will also include 'give me the longest block'
    • Question: Will we offer communication primitives to RBL and Rholang? We should write the powerbox 
  • Powerbox contains Crypto, Storage, Communications
  • The node will need to start up.  Start up communications, start up storage, start up the Rosette VM. The VM stays running, even though there is nothing to run.
    • If storage doesn't come up, fail
    • If comms doesn't come up, fail
    • If VM doesn't come up, fail

• Mike to schedule a meeting with Kent to talk about the Tuplespace implementation.
• Scala can preserve the state, We only need to update the entire state when we are sending messages from a validator set to another validator state.
• 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?
• 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.