Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Easy to convert test from ethereum/tests #1016

Open
winsvega opened this issue Dec 11, 2024 · 0 comments
Open

Easy to convert test from ethereum/tests #1016

winsvega opened this issue Dec 11, 2024 · 0 comments
Labels
good first issue Good for newcomers

Comments

@winsvega
Copy link
Contributor

winsvega commented Dec 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant