Skip to content

Instantly share code, notes, and snippets.

@axic
Last active June 1, 2019 21:24
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save axic/262834f3d2c31cf4170387bbc2de698c to your computer and use it in GitHub Desktop.
Save axic/262834f3d2c31cf4170387bbc2de698c to your computer and use it in GitHub Desktop.
Eth 2 Phase Crossover EE

"Crossover" EE

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.

"Specification"

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.)

Verified accounts

Deploying a code at an address will only happen if the submitted code passes a verification process.

Execution on a Shard

Each block to a shard needs to contain a witness (~= a partial merkle tree) of the accounts accessed or affected by the transaction.

Some options to reduce proof sizes

  1. Keep more of the Wasm system code (verification, account abstraction, other system contracts) as part of the code of the execution environment.

  2. A shard keeps the state of the past N blocks, thereby reducing the size of the witness needed.

Transaction format

A block needs to have the following properties:

  • starting state witness
  • transactions
    • destination
    • data
    • signature

The destination is like an Eth1 address.

Deployment of code

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

Executing a transaction

This will execute the account code via Wasm. The Scout EEI has to be extended with: executeCode.

TBD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment