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

Deployment tets: failure #1601

Closed
13 tasks
OlivierBBB opened this issue Dec 2, 2024 · 0 comments · Fixed by #1572
Closed
13 tasks

Deployment tets: failure #1601

OlivierBBB opened this issue Dec 2, 2024 · 0 comments · Fixed by #1572

Comments

@OlivierBBB
Copy link
Collaborator

OlivierBBB commented Dec 2, 2024

Definitions

Failure Condition F CREATE's are those CREATE's that

  • are unexceptional
  • don't abort
  • but raise Failure Condition F

Recall that this condition is triggered when the deployment address has one or more of the following properties

  • nonzero nonce
  • nonempty code

Note. Nonzero balance isn't an issue when scanning for Failure Condition F..

Sequential Failure Condition F via CREATE2

Raising Failure Condition F via CREATE2 is trivial. When testing this we should look at

  • init code
    • is empty
    • is nonempty
  • deployment 1
    • success (only if init code not empty)
      • yes
        • finishes on STOP (empty deployment)
        • finishes on SELFDESTRUCT (empty deployment)
        • finishes on RETURN (pot. nonempty deployment)
      • no
        • finishes on exception
        • finishes on REVERT
    • gets reverted before deployment 2
      • yes
      • no
  • deployment 2
    • same questions
    • raises or not the

Nested Failure Condition F via CREATE2

  • contract A does a CREATE2 with init code that calls A again to do a CREATE2 with the same init code.

Failure Condition F via CREATE

This is classical by now:

  • contract A does a CREATE2 deploying contract B
    • contract B should be able to do a SELFDESTRUCT / CREATE
  • contract B does a CREATE deploying contract C while it has nonce n (e.g. n = 1)
  • contract B selfdestructs
  • contract A re-deploys contract B using CREATE2 again
  • contract B attempts a CREATE at the same nonce n as previously, effectively attempting to re-deploy at contract C's address

I guess the simplest way to achieve this would be to have B have the following code

// contract B deployed code
PUSH1 0
PUSH1 0
PUSH1 0
PUSH1 0
PUSH1 0
CALLDATALOAD  // expecting to find an address in call data
GAS
DELEGATECALL

This byte code measures 13 bytes. The associated init code would be

PUSH13 ...
PUSH1 0
MSTORE
PUSH1 13
PUSH1 0
RETURN

which is 22 bytes. It should be deployed in a CREATE2 with 1 Wei of value.

We then need two contracts:

  • one that simply selfdestructs
  • another one that CREATEs.

E.g.

// basic CREATE-or contract (deploys 0x)
PUSH1 0
PUSH1 0
PUSH1 0
CREATE

or

// alternative basic CREATE-or contract (deploys 0x00 .. 00)
PUSH1 32
PUSH1 0
PUSH1 0
CREATE
// basic SELFDESTRUCT-or
ORIGIN
SELFDESTRUCT

The simplest scenario would be

  • transaction 1:
    • to contract A
    • deploy contract B
    • get back to A
    • CALL contract B with call data the address of the basic CREATE-or
    • CALL contract B with call data the address of the basic SELFDESTRUCT-or
  • transaction 2:
    • to contract A
    • deploy contract B (which is clean)
    • CALL contract B with call data the address of the basic CREATE-or
      • raise Failure Condition F
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants