The goal is to have some figures on the size and complexity of transaction creation and processing.
The MVP to do this consists of (in Rust):
a "state API"
has a way to access an address (contract)
has a way to access/modify storage of the current account
a basic API for contracts (can call other contracts, can read and write storage)
Two processes:
1) Transaction creation
This is kind of like how "estimateGas" works - it runs the transaction with all the starting state present. It will need to keep track of what storage is accessed (read) and what is changed (written). Then it will need to bundle all this up into a transcation blob (containing data and merkle proofs)
2) Transaction processing
This receives the transaction blob and has no underlying state (apart from the merkle roots). Will try to process the transaction. (Should also run this against invalid transaction blob, e.g. something lacking data, proofs or has invalid proofs.)
Possible variations on the "state API":
has storage keys and values of fixed size (256-bit, like ethereum)
has storage keys of fixed size, but values of unlimited size
has both storage keys and values of unlimited size
There should be a couple of different approaches implemented as trees. Possibly we could start with Ethereum's merkle-patricia tree as that would allow for a good comparision of speed and size (would we wish to write a paper).
Technically the simulation is written in Rust and has the following elements:
"state API" as a trait
wasmi for wasm execution
multiple implementations of the "State API"
at least 2 different contract examples implemented
The goal is to have some figures on the size and complexity of transaction creation and processing.
The MVP to do this consists of (in Rust):
Two processes: 1) Transaction creation
This is kind of like how "estimateGas" works - it runs the transaction with all the starting state present. It will need to keep track of what storage is accessed (read) and what is changed (written). Then it will need to bundle all this up into a transcation blob (containing data and merkle proofs)
2) Transaction processing
This receives the transaction blob and has no underlying state (apart from the merkle roots). Will try to process the transaction. (Should also run this against invalid transaction blob, e.g. something lacking data, proofs or has invalid proofs.)
Possible variations on the "state API":
There should be a couple of different approaches implemented as trees. Possibly we could start with Ethereum's merkle-patricia tree as that would allow for a good comparision of speed and size (would we wish to write a paper).
Technically the simulation is written in Rust and has the following elements: