OlivierBBB
commented
3 months ago Desiderata
A complex contract B that can CREATE2 with complex initC potentially leading to the deployment of complex contract C with complex behaviour, too. They should be able to call each other (in all possible combinations) and do other complex stuff.
Contract B
A contract B which can:
- CALL itself (with
value/gasas parameters that can be set) - STATICCALL itself (with
gasparameter that can be set) - CALL / STATICCALL C (will be defined below)
- REVERT on demand
- provoke an
outOfGasExceptionon demand (e.g. some big SHA3) - SELFDESTRUCT on demand
- run a pametrized CREATE2 with fixed init code (parameters:
value)
Initialization code initC
Some init code initC that can:
- CALL B on demand (e.g. to attempt asking B to re-deploy with initC)
- SSTORE during deployment and on demand
- SELFDESTRUCT during deployment and on demand
- REVERT during deployment on demand
- EXTCODEHASH/COPY/SIZE from either B or itself (via ADDRESS)
- CODECOPY from itself
Deployed contract C
initC should, if it leads to a deployment, always deploy the same code (e.g. obtained by an EXTCODESIZE / EXTCODECOPY / RETURN combo) or to empty deployment code or to a failed deployment. When it deploys nontrivially the resulting account C should be able to
- SSTORE, in particular at storage keys that may have been touched during deployment,
- SELFDESTRUCT on demand
- REVERT on demand
- CALL B on demand
Complex example run
Reading order:
- bottom to top
- at a node, read in clock-wise order
Slightly more readable picture (of a slightly more complex scenario)
Notes from @OlivierBBB: https://hackmd.io/@olivierbbb/SkOB9AWsC
The purpose of this issue is summarising possible approach to build an advanced testing framework.
First of all, we should check if there is already something existing and ready to use in Java.
If not:
Approach A
The testing library should allow:
linea-traceritself.Note: Currently, in order to do not create too many smart contracts to test different slightly different cases, we create larger than necessary smart contracts (e.g., in the case of
SELFDESTRUCT) and we interact with them in different ways. Such modularity, would allow a more flexible way to define smart contracts for testing that contain only what we need for the specific test case.Behaviour definition: a test case can be identified by indicating an entry point in a tree of smart contracts via a call to a function (or the constructor). A basic graphical representation (using ASCII) of the behaviour we want to test may be helpful and could be generated.
Assembly, Yul, Bytecode injection: in order to by-pass Solidity compiler restrictions and test more in depth our software, we may want to inject in the Solidity smart contracts directly assembly, Yul or Bytecode. Understanding which one is the best approach has to be researched.
Note: mapping Java on Solidity instead of Bytecode directly may make the process quicker and is not a limitation due to the observation above. Mapping Java directly on Bytecode may lead to face the complexity of creating a Solidity-like language in Java, that is unnecessary;
Feel free to add other ideas below.