sheth [ ˈshēth ] is an execution
environment
(EE) for Ethereum 2.0 that facilitates the movement of ether within a shard and
provides mechanisms to move ether between a shard and the beacon chain.
First, setup your environment:
rustup target install wasm32-unknown-unknown
cargo install chisel
make setupThen simulate execution using Scout:
make scoutOr run on your local architecture (useful for tracking down bugs):
make testThe design space for EEs is broad and builds on many different Ethereum 2.0 related concepts. If you're lost, here are a few places to get started:
Ping me @lightclients for any other questions / concerns.
- Understanding the developer experience regarding EEs could influence design decisions of the protocol and EE runtime.
- Efficiently authenticating and updating merkle multi-proofs is critical to the success of stateless execution environments.
- In order to develop strong tooling for EE development, it's important to determine a lower bound for execution time and binary size to target.
- Provide a framework on which others can develop and experiment.
At a high level, sheth provides a single state transition function:
pub fn main(pre_state: &[u8; 32], data: &[u8]) -> [u8; 32];The main function essentially takes in the latest merkle root of the state as
pre_state and some amount of data. It deserializes the data into the
transactions that will be executed and the merkle multi-proof which is used
authenticate the transactions. Due to some of the semantics of WebAssembly, it
isn't quite this simple (see the FFI interface) -- but the general
idea remains intact.
sheth's design is heavily influenced by Vitalik's sample EE in his phase 2
proposal.
The state can be thought of abstractly as an array [Account, 2**256], where
an account's index in the array is equal to Sha256(account.pubkey). This is
far too large to fit into memory all at once, so operations are done on specific
elements within a merkle multi-proof.
The sparse merkle tree for sheth's state can be roughly visualized as
follows:
FL = first leaf node = 2**256
LL = last leaf node = 2**257 - 1
+---------- 1 ----------+
/ \
+-- 2 --+ +-- 3 --+
/ \ / \
... ... ... ...
/ \ / \ / \ / \
FL+0 FL+1 FL+2 FL+3 ... LL-3 LL-2 LL-1 LL-0
Each leaf node is the root of the corresponding account. An account's merkle
tree structure is as follows:
+--- account ---+
/ \
pubkey_root sub_root
/ \ / \
pk[0..32] pk[32..48] nonce value
A merkle multi-proof is a data structure which stores multiple branches proving
various items within the state. For a formal definition, see the
specification.
Imagine a merkle tree of this shape (e.g. an account):
1
/ \
2 3
/ \ / \
4 5 6 7
In order to prove 6 is included in the root at 1, the nodes [2, 6, 7] would
be needed since 1 and 3 can be calculated from that set.
1
/ \
[2] 3
/ \ / \
4 5[6] [7]
- Support intra-shard transfers
- Consume beacon chain withdrawal receipts
- Allow shard ether to be deposited to the beacon chain
- Validate transaction signature against BLS pubkey
- Verify transaction nonce against account
- Implement
mergefunctionality for multiple packages - Minimize binary size
- Minimize execution time
- Minimize multi-proof size
Licensed under Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0)