The "crossover" execution environment aka Eth1-esque abstraction over Phase2
The current proposals for Eth 2 Phase 2 revolve around a purely stateless architecture, where the only stored information is the state root of each "execution environment" on a shard. This is in stark contrast to the stateful mode of operation on Eth1.
This model expects higher level abstractions to be built atop this simple system. Here follows one proposal to achieve a familiar environment as a higher level abstraction.
Lets assume the state structure is the same as Eth1 with a few changes:
- Wasm code is used instead of EVM
- The code deployment process is different
- Account abstraction may be introduced (like EIP86)
- An account can only exists if it has been verified
(From Proposal 2: This state is specific to the execution environment on a shard. The shard only stores the state root of it.)
Deploying a code at an address will only happen if the submitted code passes a verification process.
Each block to a shard needs to contain a witness (~= a partial merkle tree) of the accounts accessed or affected by the transaction.
-
Keep more of the Wasm system code (verification, account abstraction, other system contracts) as part of the code of the execution environment.
-
A shard keeps the state of the past N blocks, thereby reducing the size of the witness needed.
A block needs to have the following properties:
- starting state witness
- transactions
- destination
- data
- signature
The destination is like an Eth1 address.
Deployment happens via sending a transaction to a the "deployer system contract". This will run it through the verification contract and place the code if successful.
TBD
This will execute the account code via Wasm. The Scout EEI has
to be extended with: executeCode
.
TBD