Create Blockchain tests for Contract Lifecycle and Logging opcodes that consume the whole block

[kevaundray]

General context

Generally the structure of these tests are split into two:

• Setup phase
• Benchmarking block

Setup phase

The setup phase encompasses the pre-state and blocks that are needed in order to setup the block full of a specific block.
An example of this would be a "block full of EXTCODESIZE" where the setup phase would consist of N different contracts being deployed, where N is the number of EXTCODESIZE opcdes we want to put in the final block.

Benchmarking block

For benchmarking, we assume that the final block is the one with the block full of the particular opcode we want to benchmark

Opcodes

Logging

• LOG0
• LOG1
• LOG2
• LOG3
• LOG4

Contract Lifecycle

• CREATE
• RETURN
• CREATE2
• REVERT

Note

• This is a subtask of Create blockchains that consume full gas on single operations. #1453

[LouisTsai-Csie]

Could I take this one for the Logging operation?

[kevaundray]

Could I take this one for the Logging operation?

Yes please

[jsign]

@LouisTsai-Csie, @jochem-brouwer, what do you think about the RETURN and REVERT opcodes here regarding if there is a meaningful way of isolating them. Both opcodes will terminate the current stack frame, and entering any stack frame costs 100 of gas (assuming the target contract is warm already).

Regarding CREATE and CREATE2, I think we can have some good coverage by doing something like:

• Parametrize the test by opcode (i.e., CREATE and CREATE2) and code_size (e.g., 1, 10, 100, 1KiB, 10KiB, max_code_size).
• Pre-deploy some randomish contract A with code_size length.
• Pre-deploy initcode contract B: EXTCODECOPY A, 0, 0, code_size + RETURN 0, code_size
• Benchmark tx ~= While(EXTCODECOPY B + JUMPDEST + BigLoop[CREATE(2) + POP] + JUMP-back)

Considering the CREATE(2) will always be quite expensive, I don't think we have to care about the optimizations for POP or similar.

And for CREATE and CREATE2, see to squeeze param creations with PUSH0, DUPs or GAS as usual, although I don't think these things will make a huge difference since static cost is 32k. We can also keep the test simpler if that make sense.

The above is some thinking out loud of a plan for those open to thoughts!

[jochem-brouwer]

I think for RETURN / REVERT since the base cost is 0 (I think) it still allocates memory, so we could test to fill the return buffer with large sizes.

For CREATE:

I think the coverage here is already good. To deploy initcode for code_size can use EXTCODESIZE to ensure all is copied. For the benchmark tx especially for CREATE2 we can re-use the returned create address from CREATE2 as salt (so no need to POP that). This also ensures that the target address is unique (and thus deploys something). I think this is the easy way to ensure that the salt differs each time, otherwise you have to manipulate the salt in some way (e.g. ADD).

For fancy constructions do we also want to call CREATE within CREATE? Not sure if we want to test that, but maybe a CREATE tower where we keep init-ing CREATE sounds like a good idea. (This will actually deploy contracts, since at the lowest level the CREATEs will OOG, this will return to the previous frame which has gas left, which will thus succeed deploying (at least the empty contract).

Should we also test CREATE and especially CREATE2 with address collisions? (Attempting to deploy a contract when there is already code there).

[LouisTsai-Csie]

For RETURN / REVERT, the idea of testing the memory allocation is great. But what's the ideal memory size to test, is there any boundary for memory size? I have the same question for the LOG related opcode in PR #1745.

[jochem-brouwer]

There is no boundary, but if you increase the memory size, it scales quadratic with gas. So in the end it is bounded by the gas limit of the transaction. If you increase the memory size you have to pay the difference in the current size and the price of the new size. A good explanation can be found here.

[jsign]

@LouisTsai-Csie, that exact question of "up to which point makes sense to expand memory" is something you might see around in existing benchmarks (example). It's somewhat fancy/complicated; I think another strategy is having a parameter with some reasonable range-scan of values.

[jsign]

I think for RETURN / REVERT since the base cost is 0 (I think) it still allocates memory, so we could test to fill the return buffer with large sizes.

Agree sounds like a good thing to cover just in case.

For the benchmark tx especially for CREATE2 we can re-use the returned create address from CREATE2 as salt (so no need to POP that).

Nice idea! Actually I was thinking more of using GAS instead of ADD, but leveraging the returned address is better.

For fancy constructions do we also want to call CREATE within CREATE? Not sure if we want to test that, but maybe a CREATE tower where we keep init-ing CREATE sounds like a good idea. (This will actually deploy contracts, since at the lowest level the CREATEs will OOG, this will return to the previous frame which has gas left, which will thus succeed deploying (at least the empty contract).

Def a fancy experiment 😄 So you mean chaining CREATEs that deploy empty bytecode, and leveraging the 1/64 gas reservation to let only the "lowest" one fail and all the rest in the chain upstream to succeed?

Should we also test CREATE and especially CREATE2 with address collisions? (Attempting to deploy a contract when there is already code there).

Considering the static cost is 32k gas, I wouldn't expect many surprises, but we can cover that too.

For CREATE2, generating collisions should be easy by repeating salts. For CREATE, I think the only viable way is doing pre-allocs that will match a tx doing a bunch of CREATEs (i.e. each pre-alloc is the expected address on all nonce increases matching the CREATEs that will happen). Is that what you had in mind?

[jsign]

@LouisTsai-Csie @jochem-brouwer, I'll start making progress covering these remaining CREATE, RETURN, CREATE2, and REVERT, guided by the discussion above.