It would be quite easy, especially if all the opcodes are available. That’s why I decided to create a puzzle like this, but with a few extra tricks to make it a bit harder to solve (even if the tricks are mostly “smoke and mirrors”).

I announced the puzzle on Twitter two days before 2023, and it has already been solved:

https://twitter.com/0x796/status/1608553575969611777

But if you still want to try and solve it yourself before reading the rest of this article, here is the saved bytecode (the contract self-destructed after it was solved):

https://library.dedaub.com/contracts/Ethereum/0xA0Eb20483Cb60213bF944c2C3833bebc9fbc4706/bytecode?line=1

Note: the rest of this article contains a full code review of the puzzle, so it will ruin the fun if you don't want any help solving it!

SPOILERS AHEAD!

Now that all the warnings have been given, let’s dive into how the puzzle was constructed and see how I wrote the contract…

ASCII salute 🫡

To start off, why not begin the contract bytecode with an ASCII encoded string? And let’s make it thematic. Just because we can :)

I opened my fork of evm.codes, which instantly decompiles bytecode, and played around with different ASCII text to see which opcodes it decompiled to. I ended up with a “Happy New Year” greeting – and I was pretty lucky:

• “H” is ASCII 0x48, which is just a BASEFEE opcode – it can stay on the stack.

• “a” is 0x61, which is PUSH2, pushing the next two chars “pp” to the stack.

• “y” is 0x79, which is PUSH26, pushing the rest of the string with some exclamation marks at the end.

This way, at the start of the contract we have these three things on the stack – but do we really need them? We’ll see.

Unfortunately, Etherscan doesn’t have an option to show contract code as UTF-8 or ASCII (as it does with calldata). Otherwise, everyone would be able to see the greetings :-/

I realized this only after deploying the contract. But it’s a nice Easter egg (Santa egg?) for anyone who is curious.

Now let’s do the “can run anything” part

Contracts can’t run arbitrary code from input – there is no opcode for that. The only way to make them do that is by deploying the code into a new contract and then doing a DELEGATECALL – which means that the code from the external contract will be executed by the current contract in the current context. And that’s exactly what we need!

How do we deploy an external contract from bytecode? Using the CREATE or CREATE2 bytecodes. Let’s go with a simple CREATE – it just needs a few parameters, such as the value of the money to pass (0), the offset (location of the code) in memory, and the size of the code in memory.

That’s all easy, but how do we deploy a contract whose code only contains the “send money to me” instruction? How does a contract deployment happen anyway?

When a contract is being deployed on an address, it’s constructor code is executed on that address (even before the address has any code). And for the contract to be considered “deployed” and to have some code remain forever on the address, the constructor code must RETURN the deployed code at the end of its execution.

This may sound strange, so let’s see what it means in practice.

Here is a constructor code that deploys a contract with “32FF” in its bytecode:

PUSH2 0x32FF // Push 32FF into stack
PUSH1 0x00   // Push 0 offset where to save it
MSTORE       // Save it to 0 position in memory (0x00.....0032FF)
PUSH1 0x02   // Push 2 into stack (size of our bytecode)
PUSH1 0x1e   // Push 0x1E (18) - which skips all the 18 zeroes
RETURN       // Returns just 32FF from memory - this is our bytecode

After executing this constructor code, the 32FF will remain on the contract forever. Well, not forever in this case - it will self-destruct on any call :-D

There is an easier way of returning the bytecode than copying it to memory from the stack and that is using CODECOPY:

PUSH1 0x02   // Push 2 into stack (size of our code)
PUSH1 0x0c   // 0x0C is where our code begins in this code
PUSH1 0x00   // 0x00 where to save code in memory
CODECOPY     // Copy 2 bytes of code from 0x0C and save to memory
PUSH1 0x02   // 2 is size of the code in memory
PUSH1 0x00   // 0 is location in memory
RETURN       // Returns 2 bytes from 0 location in memory
ORIGIN       // This is offset 0x0C - where our code begins
SELFDESTRUCT // Origin is who called the TX, selfdestruct sends money to that address

As you can see, this is a bit different: we put our contract code "as is" - just after the RETURN, and then we just say "hey, CODECOPY from this offset please" - and we have this code in memory and return it - thus deploying it on-chain.

That's the general template for deploying some bytecode, and in our case - we need to take the bytecode from calldata and also determine its size. Luckily, we can use PUSH2 for the size, and it will also work the same as PUSH1, which will give us enough slack for deploying even 65535 bytes of bytecode (and contracts can't be that large - so that's a universal solution).

This code looks like this in bytecode:

Where instead of four zeros "0000" we should paste the size of the bytecode we are about to execute (which is equal to calldata size).

To make it a little bit more obscure - let's XOR it with our HAPPY NEW YEAR intro and deXOR it at runtime - it's on the stack already, so why not:

This will make it a little bit harder for anyone decompiling to understand why this is there. But just a little bit - any experienced developer will just be delayed a couple of minutes more.

Huffin

After some experimentation with bytecode, I've decided it's time to organize and start a Huff project - it's also a good excuse to finally learn Huff.

So far, we have this:

I've added a DELEGATECALL after the contract is deployed - it will execute the freshly deployed code.

So right now, it's all about sending 32FF to the contract and it will self-destruct while sending any money it holds back to the transaction origin (which is us).

That's still too primitive, so let's add more complexity to it: SOCIAL!

Social mechanics

Initially, I wanted to just put 0.1 ETH as a prize on the contract and that's it, but it's not as interesting as some kind of "social game" - where you need to put some of your money at stake if you feel you can solve the puzzle fast enough to win it back, along with the whole prize pool. This creates some interesting social mechanics:

• Initially, nobody would want to put their ETH on an unknown contract

• But if you've already solved the puzzle and you're 100% sure about what's happening in the bytecode, then you can safely deposit and take the prize

• But what if someone else also solved the puzzle and just waits to frontrun you, taking both your money and the prize?

That's why I've also introduced a 1-hour delay between depositing and being able to submit a solution - so no direct frontrunning is possible without also having the frontrunner's funds at stake. And also:

• You have an incentive to deposit earlier, even if you're not 100% sure about your solution - but you already know the general principles and you're going to make it within 1 hour

• If someone else has already deposited, you don't know if they already have the solution or if they're also just booking a place and still solving it

I've also introduced diminishing deposit - it goes to zero at 23:59 on December 31, 2022 - so booking a place at the beginning costs more, but diminishing still allows those who aren't sure to wait until it's cheaper, although with the cost of the prize being taken by someone else (which actually happened, but spoilers later).

Now, lets hope that these mechanics would make the game more fun and less risky to play!

Also I understood, that, as a creator, I know the solution and can frontrun anyone, so I've decided that my initial 0.1 ETH prize should be sent during contract deployment so it doesn't count as a deposit (i.e. I cannot submit solutions). This still doesn't provide any proofs or guarantees that I will not mimic an anonymous user and submit another deposit from a separate unknown wallet, but anyways, that's impossible to prove, so that's the most I could do to make the game fair.

XORing the calldata

To make it a little bit harder from a technical standpoint, I've also decided to XOR the provided calldata with the msg.sender address - this way we'll have an additional front-running protection: all solutions will be different for everyone. And this will act as an additional delay for hackers - it's not as easy as submitting "32FF" to the contract address anymore.

Writing the XOR loop in Huff was fun :) and required some effort. But in the end, here's how it looks:

How it works:

1. It takes msg.sender and duplicates it to fit the whole 32-byte slot:

0xd48B1EBb6828D1a1760b5c70aaE1aAE3CdcD18c1
                  ^^^^^^^^^^^^^^^^^^^^^^^^
  vvvvvvvvvvvvvvvvvvvvvvvv
0x760b5c70aaE1aAE3CdcD18c1_d48B1EBb6828D1a1760b5c70aaE1aAE3CdcD18c1
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

2. It calculates the size of calldata, determining how many 32-byte slots it takes - thus how many times we need to process it.

3. It processes the calldata (copied to memory already) slot-by-slot, XORing it with this duplicated msg.sender 32bit value.

After this, 32FF becomes something else - so the hacker needs to figure this out and XOR it beforehand, so the contract de-XORs it.

How all these XORs work?

A little side note: talking about all those XORs, what is happening here?

For those who don't know, XOR is a bit-operation that can be applied to two numbers.

Technically, what it does is show the difference between the bit representations of two numbers:

A = 0001110001010000111
B = 0001110001111000000
XOR 0000000000101000111
              ^ ^   ^^^

As you can see, XOR shows which bits differ between two numbers and puts 1 there.

But another interesting property of XOR is that if you XOR a number with some other number, it becomes "encrypted." Why? Because if you XOR this encrypted number with the same number again, you'll get back the original number!

Here’s an example:

A = 000111000111
B = 010101010101
XOR 010010010010

and then you XOR the result with B again:
RES 010010010010
B = 010101010101
XOR 000111000111

And you see that XOR result here is the same as A!

That's why we XOR things back and forth - to "encode" and "decode" them - that's the simplest encoding human kind has known since punch cards became a trend. Any experienced hacker knows about it, but it's still always fun!

Registering players

How do we register the players who made a deposit? It's simple - just put something in storage at the msg.sender address slot. And this something will be a timestamp - because we're introducing this 1-hour delay between depositing and the solution.

Here's how it looks in Huff:

I guess everything is clear from the comments - first, we check that a proper ETH amount was sent with the transaction (which depends on the time until NEW_YEAR), and then we register the player by saving the current timestamp + SOLVING_DELAY to storage under the msg.sender address slot.

Verifying if player was registered

And when submitting a solution, we verify if the player was registered:

It's also pretty simple - just reading from storage and comparing it to 0 (if the player was registered at all) and to the current timestamp (to check if they can already submit a solution).

Piling everything up together

Now that we have all the functions, let's put everything together into one big Huff program :)

I won't copy the screenshots of the above functions, but I'll just show you the MAIN() macro instead:

I've added some more tricks like using RETURNDATASIZE instead of PUSH1 0x00 - because in this case it does the same thing - pushes zero onto the stack. But it also saves bytecode (because it's just 1 byte) and hopefully confuses hackers a little bit more.

I've also added the "CONGRATZ" text along with "chad]" as push instructions. Why? Because the delegate_call JUMPDEST is 0x5B, which is "[", so I wanted to use that and make it look like "CONGRATZ [chad]" when you look at the bytecode :)

Honestly, I also wanted to make it a string and jump inside of it, but in the end, I found out that you can't jump inside PUSH instructions data :-( (more on that in my previous article).

Results!

So my prediction was that an experienced hacker should be able to solve this within 1-2 hours (thus the 1-hour delay). And that's basically what happened - yannickcrypto.eth deposited his stake after about an hour or two after I deployed and announced the game, and then submitted a solution in another hour or two - grabbing the prize and making the whole contract lifetime just 4 hours. Congrats to Yannick!

The solution was exactly that: "32FF" encoded, so the contract self-destructed and sent all the money to the hacker.

The code is still available on dedaub:

https://library.dedaub.com/contracts/Ethereum/0xA0Eb20483Cb60213bF944c2C3833bebc9fbc4706/decompiled?line=1

And look how amazed I was with the output of their decompiler!

It decoded everything into very readable Solidity code! And it did the best job out of all the decompilers I've tested this bytecode with (some didn't even output anything because they were probably confused by the "HAPPY NEW YEAR" intro :-D)

It's too bad I didn't know about its existence when I was testing the game, because with such code, it shouldn't take longer than 15-30 minutes for anyone experienced enough to understand what's going on, making the game too easy.

But still, it was a good experience. I hope the next puzzles and games that I make will be better and more fun to participate in!

As always, stay tuned, and if you like the content, subscribe, collect, and follow me on Twitter to not miss the fun next time!

As always - stay tuned, and if you like the content: subscribe, collect, and follow me on Twitter to not miss the fun next time!

If there is a 5B you can always jump there, right?…

Wrong!

And the answer has to do with something called instruction boundaries.

What are instruction boundaries and why do they matter?

When the Ethereum Virtual Machine (EVM) processes bytecode, it loads each octet and defines where one instruction starts and ends. These are known as instruction boundaries. Most opcodes are one-byte, with the exception of the PUSH opcodes. There are 32 PUSH opcodes, ranging from PUSH1 to PUSH32, and they all take more than one byte in bytecode for a single instruction at the program counter. When the EVM encounters anything between 60-7F, it needs to determine which PUSH it is and the size of the accompanying payload, then load everything at once as a single instruction and skip to the next bytecode byte.

But what does this has to do with JUMPDESTs? 5B is a 5B in the end! You see it in code - you jump!

Not really. If you’ve seen the Ethereum Yellow Paper, there’s a separate section there about the Validity of Jump Destinations (9.4.3):

And it explicitly states that "all [JUMP] positions must be on valid instruction boundaries, rather than sitting in the data portion of PUSH operations."

In other words, you cannot jump to a byte in the middle of a PUSH instruction.

For example, consider the following bytecode:

At first glance, it may seem like this bytecode consists of a JUMPDEST opcode followed by a PUSH1 00 opcode and an SSTORE opcode, which could potentially write something to storage. However, if we take a broader look in the context of it, the JUMPDEST opcode is actually in the middle of a PUSH instruction:

So it’s not really a JUMPDEST, but a “5b600055” number pushed into stack. Therefore, the JUMPDEST opcode is not on an instruction boundary and cannot be jumped to.

“And what about all those sweet 5Bs I saw in the beginning?”

That code was from SeaPort and actually it’s a string that contains 5B, that is pushed into the stack with PUSH32:

And the string is “ConsiderationItem[]” or whatever that means:

So the next time you see a JUMPDEST opcode in the middle of a PUSH instruction, you'll know you can't jump there.

And if you want to read and translate Ethereum bytecode into something more readable, just remember to process it sequentially and take PUSH instructions and their data into account.

Actually, it’s very easy, here’s a sample TypeScript code that does exactly that:

And here’s a bonus cherry on the top - a fully RegExp disassembler for EVM bytecode:

https://twitter.com/0x796/status/1608039943582142464

The regex strings are linked in the tweet reply - take a look! It only works in the PCRE2 flavor of regex (Perl family), so you may need to apply some tricks if your language doesn't support it.

So, in the end, we are safe and no jumps to the middle of revert strings are possible. You can breath out and make yourself a favorite hot drink.

If you like the stuff I write - subscribe, collect, follow me on Twitter and spread the word!

(or: surprising facts about the compiler's optimizer)

Imagine you have a packed struct like this in storage:

Can you guess which code will be cheaper to run:

• the one that’s reading every value from storage several times? (A)

• the one reading from a storage reference? (B)

• or maybe the one loading the whole struct into memory first? (C)

Wrong. Whatever you guessed - you’re not even close!

As Solidity developers, we're constantly on the lookout for ways to optimize our code. We read articles, follow advice from experts, and employ various techniques to ensure that our smart contracts are as efficient as possible. But, as it turns out, many of these optimization techniques may be completely ineffective.

The Solidity compiler's optimizer is incredibly powerful, and often does a better job of optimizing code than we could do ourselves. In fact, our attempts at optimization may actually make things worse, as the optimizer will often rewrite our code in ways that we can't predict (because it’s also dumb lol :)).

So the real answer to the question is - another question: What are the project’s optimizer settings?

Because the gas usage of these three functions will be completely different if:

• Optimizer is off (rare - can skip)

• Optimizer is On with default settings

• We use the new trendy VIA-IR way

The easiest and the most predictable case is without the optimizer: the resulting bytecode will be quite large and bloated and contain many SLOAD operations (like loads), but surprisingly - even for the memory mode.

Here the results are at least predictable to the common knowledge: yes, the reading the struct values one-by-one directly from storage is more expensive (+111 gas) than loading the whole struct to memory and reading from there. And Storage Refs are even more (+13 gas) expensive than direct reads.

SLOAD usage without optimizer:

• Read Directly: 4 SLOADs

• Read From Storage Ref: 4 SLOADs

• Read From Memory Copy: 3 SLOADs

You see?

Already everything you’ve been told is a lie - even without the optimizer - the loading of a packed struct into memory takes 3 SLOADs! And direct read (in this case) is 4 - cause we read things 4 times. So what will be the case when it’s 3 SLOAD for storage vs 1 SLOADs for memory?

Let’s enable the optimizer!

With default settings:

Wait… But I thought… I was told…

What the hell just happened here?

Why is Direct read from storage cheaper than caching the struct into memory?

So what happens here is: with the optimizer turned on, you will only have two SLOAD operations for the Direct and StorageRef methods, and one SLOAD for the memory method.

But, surprisingly, the memory method still is the most expensive. Why? Because while one additional SLOAD on a hot slot costs 100 gas, the operations required to read the struct into and from memory will cost more than 100 gas - and the Direct and StorageRef stuff will just use stack (which is cheaper than memory). So that’s why the additional costs.

Overall, enabling the optimizer here saved us 1000 gas overall, but had such a weird and unexpected behaviour that I don’t know what I’m doing with my code anymore…

So where is the promised 3 SLOADs-storage vs 1 SLOAD-memory and memory being cheaper? Maybe VIA-IR will give us this?

VIA-IR

Let’s try the new unexplored tech and enable via_ir:

How did memory become almost 200 more gas expensive than reading from storage??

Let’s look at the IR code:

The DirectRead and ReadFromStorageRef compiled to the exact same Yul code, so I just include one to save the screenshot space.

So if you use compilation via-IR, all three methods will use only one SLOAD! And yet, the memory method will still be the most expensive (in fact, a whole lot more expensive, by 200 gas) due to 3 more MSTORE and 4 more MLOAD opcodes used to initialize the struct in memory, rather than performing everything on the stack like the smart DirectRead method does.

So where is the holy grail of 3 SLOADs vs 1 SLOAD?

There is none.

No compilation options give the “expected” optimizooor behavior.

That’s just a lie.

It will not happen in real life.

And now you’ll have to live with this knowledge.

Conclusion

So, what can we conclude from this? It's time to reconsider our approach to optimizing Solidity code. We can't rely on our own techniques and tricks, as the optimizer will often undo our efforts. Instead, sometimes we just need to trust the compiler and focus on testing our code’s gas usage to see the real-world impact of our optimizations.

TLDR?

Test for gas usage after every “optimization” you introduce.

And don’t introduce optimizations too early - first get your code to work and make it beautiful - and then strike for lower gas.

P.S.

But, you may be wondering, is it even worth trying to optimize Solidity code at all?

The answer is yes – but only if we approach it in the right way. Instead of trying to outsmart the compiler, we need to work with it. This means using the via-IR compiler whenever possible, and being willing to let go of our preconceived notions about what makes for efficient code. We’re clearly moving towards C world, where the C compiler can already outperform any human effort in optimizing the routines (unless you don’t write really dumb code).

So, the next time you're tempted to use one of those clever optimization techniques you read about online, stop and think.

Will it actually make a difference, or will the optimizer just undo your efforts?

The only way to know for sure is to test your code and see the results for yourself. And, who knows, you may be surprised at what you find.

If you like the stuff I write - subscribe, collect and spread the word!

Let me review a recent example from RareSkills that blew up on CT a couple of days ago:

The idea is to optimize gas in the contract and run provided tests for it that have a threshold. By default, the gas is way over the target:

So the “rules” are: no messing with optimizer or solidity version, no messing with test files, use solidity (so no huff/yul/bytecode contracts), and don’t make functions payable (which is a weird rule, but ok).

🚨🚨🚨WARNING! SPOILERS AHEAD!🚨🚨🚨

Make sure you try to solve this puzzle yourself before reading further - it’s really fun and makes you learn stuff! But if you already solved it and want to read other ways of doing it, or just struggling and want to know what’s the trick - go ahead!

Let’s optimiiiiize!

Let’s do the obvious things first:

1. Make vars immutable instead of storage (saves 10710 gas - because immutable vars are embedded in the contract bytecode as constants instead of reading from storage)

2. Replace transfer with send (saves 108 gas - cause send has no check if the transfer succeeded)

3. Replace currentTime with endTime (saves 69 gas - and do the time calculations in constructor)

That gives us 61066 gas which is already 10887 better than original, but still 4k above the target:

So what’s the trick?

There’s a particular trick this puzzle should teach you. And it’s an old way of sending ETH to addresses by SELFDESTRUCT:

This trick alone saves you 4066 gas and meets the target!

But what if we go… deeper?

Every sane optimization always have its insane evil-brother… Let’s see how far we can push this!

Making the contract self-destructable already feels like cheating - why would you have a contract like this that ceases to exist after the first Distribution call? But tests are green so I guess it’s… OKAY?

Let’s see what else can leave the tests green, but optimize for more gas:

• Making contributors constant instead of immutable (saves 24 gas - cause Hardhat addresses are always the same, so why not?

• Make amount constant 0.25 ETH instead of calculating from balance (saves 106 gas - cause again, in tests the amount is always the same, so why not?)

• Use Assembly to do call instead of usual solidity address.send (saves 90 gas)

Even deeper?…

Putting addresses as bytes32 number directly in calls can save us 9 more gas units!

Allright, how bout we go all the way down?

So as far as we’re gaming tests, let’s game them even further.

Why don’t we just return if the test is “Gas Target”?

Knowing that Hardhat always runs tests in the same blocks, we can just put this in the beginning of our distribute() function:

if (block.number == 5) return;

And it will always return on the “Gas Target” test without consuming much gas, but will still do the rest of the function on “Business Logic” test :)

This gives us an amazing 21207 gas! Which is unbelievable until you understand what’s going on here…

So what? That’s cheating!

Yeah, and this space is often about cheating - MEV, exploits, code-is-law, and all other stuff: if you can do it - you do it. Remember the recent gas-CTF contests with best optimizooor getting an NFT? There nobody is solving the original problem anymore - everything’s about “cheating” the smart-contract to accept the required values and pass the required tests with the lowest bytecode and the lowest gas - and you get the #1 NFT.

And what does this mean? We all doomed?

No :) We just need better testing and better conditions. Even this gas-puzzle could still verify the business logic in the Gas Target test, and use randomized values and addresses - so there’s no incentive to write code that just makes the tests green.

If the tests are good and fuzzy - there’s no possibility of writing hacky code to just meet the minimal requirements.

Same with the CTF contests. If they tested their problem solutions many times (like 1024 times in a single transaction - all with different numbers) - first, there will be no simple block-hacking (waiting for the right randomized number to submit your solution in a particular block to pass), and also the gas-estimation would be better when using different input values.

I hope the next CTF’s and Puzzles would consider this, so the game becomes more about efficient algorithms, and not just clever ways to hack the system.

If not - I would have to write one myself :)

P.S. The solutions provided here are not optimal - there are still a lot of ways to optimize even further: I’ve seen lower numbers, different tricks (including bytecode replacement), but here I’m describing my own experience with the puzzle. And trying to raise an issue about test-fitting and how to make things better.

Cheers, and let’s discuss the tricks you discovered in CT!