You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following are the tests that are relatively easy to convert while also allowing to convert a large number of files from the tests repo in one go:
Random tests
stRandom stRandom2
In random tests need to look at the vm trace. Really are triggered like 5-6 cases of vm exceptions
I think it is enough to create minimum set of instructions that trigger the same vm exception. 1 per test.
Many tests just repeat itself.
Zero knowledge
stZeroKnowledge stZeroKnowledge2
Most tests from this folders are really just vectors for the precompiles. It is a base template with many parametrisation vectors.
stQuadraticComplexityTest
This must be not really quadratic complexity but the stress tests that call something many times. Easy to convert.
Storage overwrite combinations
stSStoreTest
This tests mainly verify the gas usage of storage touch situations x to 0, 0 to x, x to x, 0 to 0 and so on.
And refunds to when we x to 0, or 0 to x to 0.
This can be extended to also verify tstore in the same manner.
TimeConsuming tests
stTimeConsuming
Need to revisit this test logic, but as far as I remember that are basically also storage overwrite/refund combinations.
It is one template with many-many-many vector combinations. can really shrink down in python in code.
stWalletTest
stWalletTest
This are legacy tests. those are actually ever first DAO tests if I am not mistaken. this does not test much of evm, but a smart contract. we can decide if we want to drop it or keep it. can be just converted as is. but sometimes I saw this tests breaking with the protocol development, so maybe they have something.
Here all tests are basically the same template. we take [calltype] -> C1 -> [calltype2] -> C2 -> [calltype3] -> C3
where calltype are all possible call opcodes. and C1, C2, C3 contracts are recording the context opcodes results like origin, selfbalance, address and so on. then at some point can happen a revert by REVERT, OOG, and this revert can happen at C1 or C2 or C3 so really here are just
for all calltypes
for all oogtypes
for all oogposition
[calltype] -> C1 -> [calltype2] -> C2 -> [calltype3] -> C3
the type of call changes the result of context opcodes. and reverts are removing the subcall changes. so it creates interesting situations where we can see what are the values of context opcodes, which contract they are recorded to and was it really reverted when OOG* happened.
Gas Prices
stEIP150singleCodeGasPrices
Here I have some ideas. this a basic test to measure gas price of some atomic evm operations. what we really need is to have a gas schedule map in python defined for each fork. and then we test on each fork that that schedule is really what external evm charges.
by schedule I mean. intrinsic transaction gas, intrinsic call operation gas, storage access gas, hot address / call address call, base opcode gas price (I think already covered but without the schedule), memory expansion gas price formulas and so on. so here a little more work.
The text was updated successfully, but these errors were encountered:
Following are the tests that are relatively easy to convert while also allowing to convert a large number of files from the tests repo in one go:
Random tests
stRandom
stRandom2
In random tests need to look at the vm trace. Really are triggered like 5-6 cases of vm exceptions
I think it is enough to create minimum set of instructions that trigger the same vm exception. 1 per test.
Many tests just repeat itself.
Zero knowledge
stZeroKnowledge
stZeroKnowledge2
Most tests from this folders are really just vectors for the precompiles. It is a base template with many parametrisation vectors.
Precompiled contracts
stPreCompiledContracts1
stPreCompiledContracts2
This are basically vectors to test the precompiles. should be easy to convert.
Quadratic complexity folder
stQuadraticComplexityTest
This must be not really quadratic complexity but the stress tests that call something many times. Easy to convert.
Storage overwrite combinations
stSStoreTest
This tests mainly verify the gas usage of storage touch situations x to 0, 0 to x, x to x, 0 to 0 and so on.
And refunds to when we x to 0, or 0 to x to 0.
This can be extended to also verify tstore in the same manner.
TimeConsuming tests
stTimeConsuming
Need to revisit this test logic, but as far as I remember that are basically also storage overwrite/refund combinations.
It is one template with many-many-many vector combinations. can really shrink down in python in code.
stWalletTest
stWalletTest
This are legacy tests. those are actually ever first DAO tests if I am not mistaken. this does not test much of evm, but a smart contract. we can decide if we want to drop it or keep it. can be just converted as is. but sometimes I saw this tests breaking with the protocol development, so maybe they have something.
Call Combinations Interuptions
stCallCodes
stCallDelegateCodesCallCodeHomestead
stCallDelegateCodesHomestead
Here all tests are basically the same template. we take [calltype] -> C1 -> [calltype2] -> C2 -> [calltype3] -> C3
where calltype are all possible call opcodes. and C1, C2, C3 contracts are recording the context opcodes results like origin, selfbalance, address and so on. then at some point can happen a revert by REVERT, OOG, and this revert can happen at C1 or C2 or C3 so really here are just
for all calltypes
for all oogtypes
for all oogposition
[calltype] -> C1 -> [calltype2] -> C2 -> [calltype3] -> C3
the type of call changes the result of context opcodes. and reverts are removing the subcall changes. so it creates interesting situations where we can see what are the values of context opcodes, which contract they are recorded to and was it really reverted when OOG* happened.
Gas Prices
stEIP150singleCodeGasPrices
Here I have some ideas. this a basic test to measure gas price of some atomic evm operations. what we really need is to have a gas schedule map in python defined for each fork. and then we test on each fork that that schedule is really what external evm charges.
by schedule I mean. intrinsic transaction gas, intrinsic call operation gas, storage access gas, hot address / call address call, base opcode gas price (I think already covered but without the schedule), memory expansion gas price formulas and so on. so here a little more work.
The text was updated successfully, but these errors were encountered: