CREATE's with empty init code

[OlivierBBB]

Question 1: If a CREATE(2) produces is carried out but the provided initialization code is empty, does Besu create and enter a child frame ? In particular will it trigger TraceContextEnter/TraceContextExit/TraceContextReEntry ?

Our definition of carried out:

• no exception
• no abort (i.e. sufficient balance & creator call stack depth < 1024)
• no failure condition (createe has zero nonce and empty code)

Question 2: Does Besu execute a STOP opcode during the deployment ?

[lu-pinto]

1) Yes it will produce a TraceContextEnter event and it will try to execute the init code. At this stage since code is empty it will get an AIOOB exception while trying to fetch the next instruction. It will call all other trace events as any executing opcode (tracePreExecution, tracePostExecution) throughout normal execution. TraceContextExit is also called at the end of the child frame normally, as the executing state goes through the COMPLETED_SUCCESS state.

TraceContextReEntry is not called since we immediately go from NOT_STARTED state to CODE_EXECUTING without bouncing off the current loop iteration of the frame execution.

2) Yes

[OlivierBBB]

Thanks @lu-pinto , that link is makes it very clear.

[OlivierBBB]

I'm confused. @letypequividelespoubelles is debugging our implementation of precompile calls (so not CREATE's, but the code looks similar in terms of setting the current frame to CODE_SUSPENDED and creating a child frame) and it seems that upon resuming execution after the precompile we don't pass through TraceContextReEntry.

I'm asking this question here since in your comment you mention that CREATE's with empty init code don't trigger TraceContextReEntry after exiting the child frame (despite the fact that we TraceContextEnter the child frame, then TraceContextExit it.) This seems rather unintuitive and clashes with our desired implementation where TraceContextReEntry (into the caller/creator context) plays a pivotal rôle ...

[lu-pinto]

Well there might be a misunderstanding though. I meant that TraceContextReEntry is not called on the child frame since it gets cleared off of the frame execution stack after COMPLETED_SUCCESS. But the parent frame will call TraceContextReEntry since, after the child frame is cleared, the parent frame is put on the CODE_EXECUTING state and we are back at the outer loop.