Resumable EVM and heap-allocated callstack

[sorpaas]

Mostly fixes #6744. All basic things for this PR are fixed now.

• The VM interface is changed to three traits -- Exec, which starts a VM execution, and can return a resumable trap, ResumeCall/ResumeCreate to resume execution from call or create traps. Those are accessed using trait objects.
• Externalities::call/create now has an additional parameter trap. If trap is true (the case for EVM), then this function would return a trap. If trap is false (the case for Wasm), then it will directly execute the context.
• Split call/create calls in Executive to use a separate struct CallCreateExecutive. This is the main struct that handles all resumes. One can use CallCreateExecutive::exec/resume_call/resume_create to get the resume behavior, or use CallCreateExecutive::consume to get the non-resume behavior.
• A refactoring on tracing mod. This makes it to use a single struct to record subtracing infos so that executive does not need extra work to record them.

Things to be done:

• Tracing mod is not working yet.
• Fix all current tests and write tests for resumes.
• Fix all TODO proof messages.
• Find a way to insert crossbeam again. In rare cases we can still exceeds current call stack limit (if too many Wasm contexts are stacked).
• Provide a compile feature flag to enable wasm trap. With pause PR merged to wasmi, that's doable. (This PR is already getting big, let's do this in another PR.)
• Make sure we don't have extra clones.

[debris]

@tomusdrw let's review this together by the end of this week :)

[debris]

lgtm, just a few minor grumbles. Would be good to get another pair of eyes to look at it

[debris]

why is Err turned into Ok here?

[sorpaas]

If ext.create returns Err, it can only be a trap. (That also means that if trap parameter is passed false, Err case is impossible.) So in here if we want to trap the interpreter, we can directly match this.

We really have three cases for the exec_instruction return type:

• vm::Result::Err which indicates some errors happened.
• vm::Result::Ok(Instruction::Result::Trap(..)) which indicates that a trap in the EVM happened.
• vm::Result::Ok(..) which indicates some other instruction results.

Putting Trap to error and wrap vm::Result::Err can also work, but it means that we need to replicate a lot more From/Into impls to support ? syntax in this function, and I think it may be a little bit overkill.

[debris]

why is Err turned into Ok here? I just don't understand the flow :)

[sorpaas]

Looks like the same case as #9360 (comment)

[debris]

is there any way we can avoid those panics?

[sorpaas]

We can create traits similar to what we do for vm:

pub trait Exec: Send {
	fn exec(self: Box<Self>, state: &mut State<B>, ...) -> ExecutiveTrapResult<GasLeft>;
}

pub trait ResumeCall: Send {
	fn resume_call(self: Box<Self>, state: &mut State<B>, ...) -> Box<Exec>;
}

pub trait ResumeCreate: Send {
	fn resume_create(self: Box<Self>, state: &mut State<B>, ...) -> Box<Exec>;
}

However, they would need to use traits objects and dynamic dispatch, which is a small amount of runtime overhead. I think it may be a good idea to only use those when in the future we want to expose Executive to be some sort of public API.

[debris]

maybe it's worth introducing a third variant? or redesigning the implementation to avoid dummy data creation?

[sorpaas]

I think this may be okay. U256::zero(), Vec::new(), Address::default() all would just zero out the fields, and wouldn't allocate anything on the heap.

• From performance's perspective, it wouldn't make any difference if we do dummy data creation or use Option, they would both just zeroing out the fields.
• From clarity's perspective, this dummy data creation is restraint in ExecutiveTracer and doesn't add any complexity outside of it.

[5chdn]

Could I get a 2nd review here @fckt @andresilva :)

[NikVolf]

would be nice to write why they are always balanced

(and many of those below)

[debris]

🎉