Enhancement: Create a read-only version of nodeos

[heifner]

In addition to #92 . Provide a mode where nodeos will never attempt to write to disk. It can start from a snapshot, run without any disk activity, and shutdown. Each startup would require a snapshot to launch.

• Set Enhancement: allow nodeos to run in "no blocks.log" mode #92 to 0.
• Do not write out forkdb on exit.
• Do not sync chainbase to disk (run in pure heap mode)
  • Including oc
• @stephenpdeos to create placeholder issue for proposal

[arhag]

In the future, if the P2P protocol was updated to allow automatically downloading snapshot state from peers, then it could even shut down and start up without requiring a new recent snapshot file to be moved to disk to load from (or continue to start from an increasingly old snapshot and require more sync time).

But in that case, there is a concern of the node knowing whether to trust the snapshot state provided to it over the network. I imagine this feature being most useful in a trusted local network with fast pipes between nodes. But it would be best to have additional security regardless.

It could write the snapshot integrity hash of the last irreversible block on shutdown so that it knows how to check the state it would re-download on startup to not be tricked. The first time bootstrapping would require either loading from a trusted snapshot file or having the operator explicitly provide the snapshot integrity hash corresponding to the state at the block height it requests to start from.

[arhag]

I think it could be useful to allow an option in which OC compiled contracts are still written to disk. The disk IO is probably not that significant for the OC database and the time spent trying to recompile accessed contracts after each startup could be very significant that it seriously hinders syncing.

OC compiled artifacts are tricky given that we do not want to include them as part of the portable snapshot file (potential determinism concerns regarding generated artifacts) but those compiled artifacts would ultimately be necessary for timely computation in a network where the BPs have all adopted EOS VM OC as the runtime (and its power is being effectively used in the network).

I'm sure a lot more thought needs to be given on how to handle OC. Fortunately, right now with the still standing recommendation to not use OC in public networks, these problems can be pushed off for the time being since nodes should be able to get away with syncing to public networks using the runtime of EOS VM JIT only.

[stephenpdiesel]

@heifner to author a proposal as a PR into proposals within product repo for further discussion