Solidity on truegav

ecrecover has been lying for eight years and your code still trusts it

Fri, 05 Jul 2024 14:00:00 +0530

The liar at address 0x01

There is a function baked into the EVM protocol at 0x01 that has been deceiving developers since the Frontier release in 2015. Not a smart contract bug. Not a compiler issue. A precompile. Hardcoded into every Ethereum node. When ECDSA public key recovery succeeds, it returns the signer’s address. When recovery fails, it returns address(0).

Zero. The null address. Delivered with the emotional affect of a cinder block. No revert. No event. No error state. Just zero.

You put msg.value in a loop and lost money, what did you expect

Thu, 28 Sep 2023 14:00:00 +0530

The variable that never moves

msg.value does not change inside a loop. That sentence has cost the crypto industry more than a hundred million dollars and it will cost more because the sentence is technically correct and the mental model of every developer who writes a loop is technically wrong and the EVM has no mechanism for caring about the distance between the two.

msg.value is established once at the start of a transaction. It holds the total ether attached. It persists unchanged through every internal call, every delegatecall, and every iteration of every loop in the entire call tree. It never decreases. It never subdivides. It holds one number from the first instruction to the last.

Your inheritance chain is a crime scene and you are the suspect

Thu, 15 Jun 2023 14:00:00 +0530

The quiz

contract A { function foo() virtual pure returns (string) { return "A"; } }
contract B is A { function foo() virtual override pure returns (string) { return "B"; } }
contract C is A { function foo() virtual override pure returns (string) { return "C"; } }
contract D is B, C { function foo() override(B, C) pure returns (string) { return super.foo(); } }

What does D.foo() return?

If you said B, your diamond inheritance contains a bug and you do not know it. If you said C, you either understand C3 linearization or you guessed and your luck will expire on the next diamond you deploy. If you said some variation of “I have no idea,” congratulations on being honest. You are in the majority. The majority is where protocols get drained.

OpenZeppelin fixed this five years ago and your code still has it, why

Wed, 18 May 2022 14:00:00 +0530

Two functions

Solidity provides two encoding functions for preparing data before hashing. abi.encode pads every argument to a full 32 bytes with zero-fill. abi.encodePacked concatenates raw bytes with nothing separating adjacent arguments.

abi.encodePacked(address(0xdead), uint256(0xbeef));
abi.encodePacked(address(0xdead000000000000000000000000000000000000), uint16(0xbeef));

These two calls produce identical byte output. An address with trailing zero bytes next to a small uint packs into the exact same bytestring as a different address next to a large uint. Hash this output and use it as a signature commitment. An attacker can forge equivalent messages by shifting the type boundary between the arguments because the padding that differentiates them does not exist.

I found your extcodesize bug, I am better than your auditor, and I am tired

Thu, 10 Feb 2022 14:00:00 +0530

The liar embedded in the protocol

extcodesize has been lying to Solidity developers since the Ethereum genesis block. Every developer discovers this lie during an active exploit. Never during development. Never during the audit. Never during code review. Always during a production incident while funds are exiting the protocol.

function isContract(address addr) view returns (bool) {
    return addr.code.length > 0;
}

This function is inside your deployed bytecode. It compiles without warnings. It passes every test you wrote. It is catastrophically wrong during the only moment in its operational lifetime when correctness matters.

Six years after the DAO and you still write this bug, fucking embarrassing

Sun, 20 Jun 2021 14:00:00 +0530

The beetle that will outlive you

The DAO was drained for sixty million dollars on June 17, 2016. I have reviewed twelve contracts in the last six months. Every single one contained the exact same reentrancy bug. All twelve were audited. Some by firms whose LinkedIn profiles you might recognize.

If a bug could win a Darwin Award for persistence, this bug would have a trophy case the size of a warehouse. It has survived every EIP. Every hard fork. Every static analysis tool. Every blog post titled “How to Prevent Reentrancy Once and For All.” It is the roach of the EVM. It was here before you learned Solidity and it will be here after you retire.

Delegatecall is a war crime and I keep committing it

Mon, 15 Mar 2021 14:00:00 +0530

Three opcodes and two want you dead

The EVM provides three ways to invoke another contract.

call sends ETH and returns data. Civilized. Predictable. What a normal engineer would design.

staticcall is read-only and cannot modify state. Has never caused anyone harm.

delegatecall runs the target’s bytecode inside your storage context. Your balance becomes their balance. Your identity becomes their identity. The target code reads your variables and writes to your slots using its own names. The EVM sits in the corner and allows this because the EVM was designed by people who considered this an acceptable tradeoff between code reuse and safety.