Open lorenzogentile404 opened 3 weeks ago
@lorenzogentile404, is it working as expected with the code snipped above? Can we close this issue?
As discussed in our call, while the tests are passing with this patch (and also if we provide an empty set of addresses), the patch leads to a bug in the tracer where Besu says transactions are successful while we expect them to fail in the two tests using a deployment transaction @Gabriel-Trintinalia @OlivierBBB
This patch basically disables some exception from the EVM-London (invalidCodePrefixException
and maxCodeSizeException
, both related to RETURN in deployment contexts) and cannot be integrated.
In this testing class we deliberately try to trigger the
INVALID_CODE_PREFIX
andMAX_CODE_SIZE
. The first two tests of the class try to achieve it by executing a deployment transaction with a payload that returns a portion of memory starting withEIP_3541_MARKER
or greater thanMAX_CODE_SIZE
respectively. The last two, achieves the same result by usingCREATE
instead of a deployment transaction. What we observe is that, while the last two tests correctly trigger the expected exceptions, the first two encounter a Java exceptions that seems to be related to Besu. Below the exceptions we encounter:First test:
Second test:
@Gabriel-Trintinalia suggested this:
I believe it happens because of the
ContractCreationValidation
rules. In here ->ExecutionEnvironment
class, in thegetProtocolSpec
try adding