I think it has to be done in the beacon chain. The reason is that there’s no good place to mark it failed if the validation occurs in the shard chain; shard chains don’t have the ability to directly write to beacon chain state, so you would have to separately mark it failed in every shard, which is even less efficient than just doing it in the beacon chain.
There’s no limit to execution time in the current design.
I was assuming by default some fixed gas limit; if desired it could also be a beacon chain state variable that can get voted up or down over time.
Core EEI proposal
Question: why make the first three an EEI instead of just passing them as arguments to the function? Or is it lower complexity to do it this way?
Question: Should the modified state also be returned (not just the state root)?
The consensus layer doesn’t recognize any concept of “state beyond the state root”; from the consensus layer’s point of view, the state root is the state. So, no.
Question: What other data from the shard state, shard block or beacon block should be made available to the scripts?
Maybe shard ID? In general, any needed info can be Merkle proven from the shard state so we can afford to be fairly minimal here.
Extensions
Are we really giving up on the idea of linear-pass-compiling callable WASM contracts stored on the beacon chain to get any needed efficiencies? To me that sounds like a really tragic thing if we end up going that way; we’d end up imposing a lot of load on all the different clients asking them to keep adding new implementations of different crypto primitives.
In the short term, I think bignums are ok because of their universality, BLS is ok because we are using it for plenty of things already, and same with SHA256, but everything else is much harder to justify. I don’t see a need to have a protocol-level SSZ library; SSZ is not computationally intensive, and we could just implement the library in WASM code and make it be a callable beacon chain contract.
From Vitalik’s optimistic receipt root design,
expected_rootswould be another important data struct to provide to execution environments.
Optimistic receipt roots are theoretically implementable entirely as a higher level concept; basically you would have a light client of some other shards inside each shard. Though I suppose if we want to ensure it keeps being funded we could enshrine it…