Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Jump to a thread:

Table of Contents

  • Have we settled on a definition of node? I use the term to refer to a single instantiation of the entire rchain system, whether it's processing the whole blockchain or not.

  • You wrote, "Nodes verify transactions in given namespaces, and transactions are i/o events across names."  How do nodes claim a namespace?  Are there restrictions on the nodes that can participate in verifying transactions in a namespace?

→ Lucius Meredith : Nodes enlist in a namespace.  It says that it is willing to serve it.  All comers are welcome.  No nodes are excluded.  There would need to be an access protocol.  We can solve this by using un-guessable names (like Google Calendar).  They can see all the names of the contracts they are executing.  The trick is that a biz private thing would have a namespace with long random urls.  Anyone wanting to sniff that would have to already know the namespace.  The other solution I came up with involves building contracts that act as if they are channels.  They build a channel over an assembly of channels, dispersing the information and re-assembling the information as a part of a protocol.  Then it becomes much more difficult to sniff the socket connections.    

  • think a single VM can run codes from multiple contracts concurrently. Does a node contain only a single VM? Multiple concurrent VMs?

→ Michael Stay (Unlicensed): > Does a node contain only a single VM? 

Semantically, it shouldn't make a difference.  Practically, we're making the VM as functional as possible, so I think we'll be able to run lots of them in parallel well if we want to.

Nash Foster

It seems like it would make a large difference to the system, since a Linux kernel can manage a container running a VM to ensure that other containers get CPU and other resources, but if all the VMs run in the same container/VM image, then the kernel can't make your job easier and more reliable.
I.e., it's **really** wrong to run all contracts in the same VM if you expect them to do any interesting amounts of work.

  • How is timeslicing among different contracts running on a single VM handled? Is there a phlogiston-based incentive to run one over the other when there's a choice?

Kent says that at the moment there is no use of asynchrony by the output of the compiler.  Is there a layer between the grey JVM and the orange Rosette VM stuff that wakes up an idle Rosette VM and adds new strands?