De-risking Execution environments by adding value-holding EEs

[villanuevawill]

Previous discussions around this VHEE have labelled it as the “Generic Asset” EE. The discussion started in this response:

One fee market EE to rule them all

You’re correct that moving the balance of beacon eth between EEs on the beacon chain would not be a synchronous call and requires a crosslink to form and a receipt to absorb from a shard/EE that pegs to it. Even if we assume this proposed design pegs all fees to beacon eth, this would still simplify the proposal by just generating one account balance per EE/slot for the proposer vs. multiple receipts generated for each submitted transaction package on each EE. I also am on board with agreeing on…

@matt followed up with a simple example:

One fee market EE to rule them all

There are a couple attributes of a generic asset EE that I think are desirable: The EE can be rigorously tested and formally verified, allowing anyone to deploy an asset with full confidence that the implementation is secure Allows for upgrades to all assets if need be Simplifies the transfer of value between EEs No need to for approve -> transferFrom as assets are first class I’m imagining this execution environment looking something like the following (just trying to get the broad strokes o…

In order for this approach to be optimal, there needs to be some concept of synchronous calls between EEs on the same shard. In the threads linked above, we advocated for this and had advocated for it previously on other forums. If there is pushback against synchronous calls between EEs, we may at the very least want to consider supporting synchronous calls for “utility” EEs such as for the Generic Asset or VHEE. An exercise to the reader of identifying other possible “utility” EEs (oracles, interpreters, etc.). Synchronous calls & generic asset EEs were also discussed here: State Providers, Relayers - Bring Back the Mempool

@dankrad

In order to be useful, the VHEE needs to have a very flexible notion of ownership. If it only provided value transfers, then it could not be the basis for a true Ethereum ecosystem. Instead, I think the best notion of ownership is something similar to the “Pay to Script Hash” (P2SH) known in Bitcoin: An address in the VHEE would be the hash of a script that validates transactions from this address. The effective owner of the funds is thus whoever can create valid inputs for this scripts, which allows for many different kinds of ownership:

Using a P2SH seems like a significant improvement over what we had originally envisioned. It avoids “fragmentation” between EEs. We originally considered a system where an account may have different balances across different EEs (as shown in the 2nd link). Some cons may be slightly increased execution and data for the submitted script. However, it decreases the amount of calls needed from the fragmented approach.