In this article, we’re going to have a look into the solution for Huff Challenge #5. If you wanna check-out the solutions for other challenges, look here.
The challenge we're examining today revolves around message signatures. Our goal is to create a contract using Huff, that takes a signature as input from the calldata, verifies if the message was indeed signed by the sender of the transaction, and returns true if it was. If the message wasn't signed by the sender or if the calldata doesn't adhere to the expected structure, we want the contract to do something that causes the transaction to run out of gas.
Here’s the solution for your quick glance:
#define macro MAIN() = takes (0) returns (0) {
/// Check if calldatasize is 97 bytes (MessageHash=32, Signature=65)
calldatasize
0x61 eq
extractParamsAndStore jumpi
oog jump
extractParamsAndStore:
/// Store the message hash
0x00 calldataload
0x00 mstore
/// Store 'v'
0x60 calldataload
0x3f mstore
/// Store 'r'
0x20 calldataload
0x40 mstore
/// Store 's'
0x40 calldataload
0x60 mstore
/// Prepare stack for 'ecrecover' staticcall
0x20
0x00
0x80
0x00
chainid
gas
staticcall validate jumpi
oog jump
/// Check if caller==retdata (signer address)
validate:
0x00 mload
dup1
caller
eq valid jumpi
oog jump
// Return true
valid:
chainid
0x00 mstore
0x20 0x00 return
// out-of-gas
oog:
0x01 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff mstore
If the above code is all Greek and Latin to you, don’t worry. I’m here to break it down for you.
#define macro MAIN() = takes (0) returns (0) {
calldatasize
0x61 eq
extractParamsAndStore jumpi
oog jump
The first part of the contract is responsible for checking whether the calldatasize
equals 0x61
(which is the hexadecimal representation of 97
in decimal). 97
bytes is the expected size of the calldata (MessageHash=32 bytes, Signature=65 bytes). If the size is correct, it jumps to the extractParamsAndStore
label. Otherwise, it jumps to the oog
(out-of-gas) label to make the transaction run out of gas.
Assumption*: The contract assumes that the calldata is structured in a specific way (message hash first, followed by the v, r, s components of the signature). If the input doesn't follow this structure, the contract won't function as intended.*
Next, we extract parameters from the calldata:
extractParamsAndStore:
0x00 calldataload
0x00 mstore
0x60 calldataload
0x3f mstore
0x20 calldataload
0x40 mstore
0x40 calldataload
0x60 mstore
This part of the code extracts and stores the message hash, v, r, and s values from the calldata. These values represent the signed message we're looking for. The calldataload
operation takes the start byte from the calldata, and mstore
stores this data in memory.
We then prepare the stack with parameters for the ecrecover
call:
0x20
0x00
0x80
0x00
chainid
gas
staticcall validate jumpi
oog jump
A staticcall is made to the precompiled contract residing at the address 0x01
. It implements the ecrecover
method. It is used to extract the signer’s address from the signature using message hash, v, r, and s values as input. The jumpi
instruction then checks the outcome of the ecrecover
call. If it's successful, the control gets transferred to the validate
label. Otherwise, it jumps to oog
, causing the transaction to run out of gas.
Assumption*: The above piece of code assumes that the contract will be deployed on the Ethereum mainnet as you can see we use chainid
as the target address of static call where the precompile for ecrecover
resides. To learn more about precompiles, look here.*
The contract then verifies if the extracted signer’s address matches the transaction sender’s address:
validate:
0x00 mload // [rcvd_address]
dup1 // [rcvd_address, rcvd_address]
caller // [msg.sender, rcvd_address]
eq valid jumpi // [msg.sender == rcvd_address?]
oog jump // if not equal, jump to out-of-gas block
The mload
operation loads the signer's address from memory which is be the return value of the ecrecover
call, dup1
duplicates this address on the stack, and caller
gets the address of the transaction sender. The eq
operation checks if the two addresses match. If they do, the program jumps to the valid
label. Otherwise, it jumps to oog
, again causing the transaction to run out of gas.
Finally, the contract returns true in the case of a valid signature:
valid:
chainid
0x00 mstore
0x20 0x00 return
This section stores the current chain id (which serves as a boolean value 0x01 for Mainnet to represent true) into memory and returns it.
And in case of invalid calldata or signature, we run out of gas:
oog:
0x01
0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
mstore
This code tries to store a massive value into memory, thereby using up all the available gas and causing an out-of-gas error.
You can find a runnable PoC including tests for all the Huff Challenges here:
To learn more about Huff, join the Huff developers discord server:
Stay tuned… Until next time 👋👋