kumavis+wanderer phone meeting notes

[kumavis]

here are the notes from our call. we should break these into issues once we know what we want to do.

cc @wanderer

app.vm

• very light
• used by rpc
• used by block processor
  • emits log events on incomming LOGs
• BAD - blockProcessor messes with app.vm.stateTrie, puts it in checkpointed state
• app.vm.trie should be guaranteed to never be in a checkpoint state

---

• vm doesnt need whole (stateful) blockchain, just (stateless) block absolute number lookup method
• eth_call should use specified block
• eth_signedTransact should (1) validate block (2) broadcast (3) not run it
  validate:
  • transaction.validate()
  • check if balance is sufficient
    this is done in the BlockProcessor
• app.vm is shared by rpc and block processor -- during processing the rpc could read state that will be reverted ( BAD )
  • app.vm.trie should be guaranteed to never be in a checkpoint state
  • block processor should work with a scratch vm while validating and then commit and emit logs
• rpc instances will need to hear about LOGS
• "SmartBlockchain" object that tracks current location and emits logs?
  • this is kinda what node-ethereum already does but is not opionated about how the data is hooked up
  • e.g.: could use RemoteBlockchain RemoteStateTrie, etc -- whatever makes sense

[wanderer]

alternative would be an smart block processor which would emit events and run its own instance of the vm.

[wanderer]

ether way I think emitting logs shouldn't be handled directly by the VM, it should just return logs

[kumavis]

ether way I think emitting logs shouldn't be handled directly by the VM, it should just return logs

@wanderer I agree

[wanderer]

update: the blockprocesser has been moved to ethereumjs-lib.