4

I have a simple empty contract:

contract test {
}

That I compile on Remix using different versions. I notice that the compiled output is getting more and more complex with later compiler versions:

0.4.4:  PUSH1 0x60 PUSH1 0x40 MSTORE PUSH1 0xC DUP1 PUSH1 0x10 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN PUSH1 0x60 PUSH1 0x40 MSTORE PUSH1 0x8 JUMP JUMPDEST PUSH1 0x2 JUMP 
0.4.5:  PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE PUSH1 0x0 JUMPI JUMPDEST PUSH1 0x9 DUP1 PUSH1 0x15 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN PUSH1 0x60 PUSH1 0x40 MSTORE JUMPDEST PUSH1 0x0 JUMP
0.4.9:  PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE ISZERO PUSH1 0xB JUMPI INVALID JUMPDEST JUMPDEST PUSH1 0x33 DUP1 PUSH1 0x19 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN STOP PUSH1 0x60 PUSH1 0x40 MSTORE JUMPDEST INVALID STOP LOG1 PUSH6 0x627A7A723058 SHA3 0xbb DELEGATECALL AND SWAP3 PUSH31 0x9A9ED68B77570A6681F22466F197FC4F1257401228E4A4722BDE9A00290000  
0.4.12: PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE ISZERO PUSH1 0xE JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST JUMPDEST PUSH1 0x36 DUP1 PUSH1 0x1C PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN STOP PUSH1 0x60 PUSH1 0x40 MSTORE JUMPDEST PUSH1 0x0 DUP1 REVERT STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 0xed SWAP6 0x4f CALLDATASIZE 0xc2 0xee 0xd1 PUSH17 0xCCD896EFE39A5BCBD2F6A71C61439DD674 0xad MSTORE8 SWAP3 0x26 PUSH8 0x6C8D002900000000
0.4.13: PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE ISZERO PUSH1 0xE JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST JUMPDEST PUSH1 0x36 DUP1 PUSH1 0x1C PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN STOP PUSH1 0x60 PUSH1 0x40 MSTORE JUMPDEST PUSH1 0x0 DUP1 REVERT STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 PUSH21 0x1D73368737655E9A09C3993DB87B5BCD07A9C28FC7 0xe3 JUMPI LT 0xdf 0xae SWAP9 PUSH23 0xF56780029000000000000000000000000000000000000 

Only looking at the init code (everything that precedes the second PUSH1 0x60 PUSH1 0x40 MSTORE) I see an increase in complexity. This seems important as everyone is paying gas for this and I would like to understand why this is necessary.

EDIT: I assume that the section CALLVALUE ISZERO PUSH1 0xE JUMPI is a conditional jump to the first JUMPDEST at 0xE if no Ether have been sent along, otherwise we run into a REVERT which seems to require two 0x0 (?) on the stack. But then it gets weird with the two JUMPDEST that follow each other and a lot of things that are getting pushed onto the stack around the CODECOPY.

1

One source of the overhead you discovered is the added swarm hash (32 bytes) at the end of the bytecode. See also here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.