Problem: socket protocol interface design about sputnikvm HOT 6 CLOSED

perfect, but before we do this. I feel very uncomfortable using an "error" to direct code execution flow, let's first isolate / come up with a name that'll describe this valid approach. It's basically an optimistic execution but will fail if there's an extern call. So in this way it's functionally deterministic. In another way it could be seen as a type of machine learning. In that one could have some kind of inline cache which remembers the needed state for X contract. (I'm not proposing that this is implemented).

from sputnikvm.

Need More Information -> NMI. I'd prefer we use this convention over an error. We delegate the concept of an error to be an actual execution problem of the VM. Does this sound reasonable?

from sputnikvm.

Please continue discussion about NMI here: #96

from sputnikvm.

I updated the description accordingly. We can use this now to design the protocol first.

from sputnikvm.

Being done as https://etcrfc.that.world/16-EVMJSON

from sputnikvm.

Correct reference is https://github.com/ethereumproject/rfc/tree/master/16 as etcrfc.that.world will be deprecated

from sputnikvm.