design
design copied to clipboard
Eth 2.0 Phase 2 with "precompiles" proposal
The execution engine part is mostly found here: https://notes.ethereum.org/s/HylpjAWsE#Shard-processing
Official discussion thread: https://ethresear.ch/t/a-layer-1-minimizing-phase-2-state-execution-proposal/5397
We should investigate the feasibility of this proposal in ewasm and provide feedback on the ethresearch forum.
A translation of the proposal into (non-comprehensive) Ewasm design follows:
- Entry point is
main(), receives no arguments - The following EEI methods are defined:
getDataLength() -> i32copyData(offset: i32ptr, length: i32, memoryOffset: i32ptr), wherememoryOffsetis the memory area of the current execution to copy data tosetStorage(key: i32ptr, valuePtr: i32ptr, valueLength: i32)getStorageSize(key: i32ptr) -> i32getStorage(key: i32ptr, offset: i32, length: i32, memoryOffset: i32ptr)saveReceipt(target: i32ptr, dataPtr: i32ptr, dataLength: i32)call(id: u64, dataPtr: i32ptr, dataLength: i32) -> i32where it returns execution statusgetResponseSize() -> i32size of the data returned by previouscallgetResponse(offset: i32, length: i32, memoryOffset: i32ptr)currentShard() -> u64getRecentBeaconStateRoot(slot: i32, memoryOffset: i32ptr)getRecentShardStateRoot(slot: i32, memoryOffset: i32ptr)abort()to signal failurefinish()to signal successexecuteCode(codePtr: i32ptr, codeLength: i32, dataPtr: i32ptr, dataLength: i32)
Differences to @vbuterin's version:
- adapted it to the fact that wasm cannot handle 256-bit data natively
- execution input (data) must be retrieved via
copyData callreturns a result code and data must be retrieved separately