The Wall

Line 22 takes an address and returns nothing, and line 18 says what it does with it: delegate the current call to that address. `internal`, so only this contract and the contracts built on it may reach it, and `virtual`, so a later contract may replace it.

Line 20 makes an odd promise. This function does not return to its internal call site, it returns directly to the external caller. Then line 23, and the reason people close the tab. `assembly` opens a block written one machine instruction at a time, below the language.

Read line 27 as three arguments. Where to write, where to read from, and how many bytes to move. What it reads is the calldata: the run of bytes that arrived with this call, the same kind of run you handed to a library by hand in the last checkpoint.

Function first: copy the incoming call data into memory. The name is `calldatacopy`, and the length comes from `calldatasize()`, the machine answering how many bytes arrived. Lines 24 to 26 say why writing at position zero is safe here: this block never hands control back to Solidity.

Line 31 is the call. Hand it all the gas available, the implementation address, where the input starts and how long it is, then where to put the answer and how much room to leave for it. `let result :=` keeps what comes back, which is one or zero.

The first four arguments you can read straight off the line. The last two are both `0x00`, and the comment on line 30 explains that pair. Decide what it is saying before you read on.

Line 34 is the collection. The same three arguments as line 27, with `returndatasize()` where `calldatasize()` was: how many bytes came back, now that there is an answer to count. Everything the implementation returned is now sitting in memory from position zero.

Line 36 looks at `result` and picks a branch. Function first: run whichever branch matches this one value. The name is `switch`, `case 0` is the branch for zero, and `default` is every other value. Both branches hand over the very same bytes. Only the verb differs.

Here is the block whole. Twenty three lines, and most of them are a comment, a brace, or a blank. Five lines move something, and the rest is explanation and punctuation. That ratio is normal, and it is the reason a block like this looks far worse than it reads.

Copy what arrived, make the call, copy what came back, then leave by one of two doors. Tap the five numbered lines and read what each one moves. After this, no assembly block you meet on a block explorer is a wall.

Line 51 declares a function that hands back an address and then stops at a semicolon. You read that shape in an interface: a name, a type coming back, and no body anywhere. `virtual` marks it as the thing a later contract is expected to write.

Lines 48 and 49 say it plainly. This should be overridden so it returns the address the fallback delegates to. Which is exactly why line 16 says `abstract`. Nothing in this file names an address, and nothing in this file can. Somebody else fills the hole.

Line 59 is the whole of this function. Read it from the inside out: ask `_implementation()` for an address, hand that address to `_delegate`, and the block you have just walked runs against it. Two declarations, joined by a single line of code.

Line 56 repeats the promise from line 20, and by now you know why it has to. Nothing after line 59 ever runs, because the block leaves by returning or reverting and never climbs back up. There is no tidying up left to do in here.

Line 66 is `fallback()`, which you met in Act One: the function that runs when a call arrives naming something this contract does not have. `payable`, so wei may arrive alongside it, and `virtual`, so a later contract may replace it.

Its body is one line, and that line is `_fallback()`. So the four declarations form a single chain, and the chain begins with a call that matched nothing at all. Trace one call all the way through it before you read the last two boards.

Take the comments away and sixty nine lines come down to five. A contract that never deploys alone, a block that borrows code from an address, a declaration with no body, a line joining those two, and a door that catches everything unmatched.

This is why anyone writes the pattern. The address in that hole can be a different address later, so a deployed contract can be given new code without moving. The storage stays exactly where it is, and the code it runs does not have to.

Sixty nine lines, and you have now read all of them. Twenty four are code, seven of those are a brace sitting alone, and the rest is a licence, a release stamp and four blocks of prose explaining the four declarations underneath them.

You can name the instruction, walk the block a line at a time, and point at the declaration that is deliberately empty. One question left, and it is about what this file can and cannot tell you.

Four declarations and one block. A door that catches everything unmatched, a line that reads an address somebody else supplied, and twenty three lines of instructions that borrow the code at that address and run it right here.

The next time an explorer hands you a short file full of assembly and no functions you know, you will place it in a second. The contract you actually wanted is at another address, and you now know which line to read to find out where.