Deconstructing a Solidity Contract — Part VI: The Metadata Hash

In the last article, we noticed that the runtime bytecode generated by the Solidity compiler appends a strange structure after the function bodies block. You can see this in the deconstruction diagram or in the image below referred to as the “metadata hash”:

Deconstructing a Solidity Contract — Part V: Function Bodies

The function body is precisely what the function wrappers detour to, after unpacking the incoming calldata. By the time a function body is executed, the function’s arguments should be sitting comfortably...

Deconstructing a Solidity Contract — Part IV: Function Wrappers

In the last article, we saw how the function selector acts as a hub or a switch of sorts in our BasicToken.sol contract. It sits at the entry point of a contract and redirects execution to the matched function of the contract the caller wants to run.

Deconstructing a Solidity Contract — Part III: The Function Selector

In the previous article, we identified the need to separate a contract’s bytecode into creation-time and runtime code. Having made a deep dive into the creation part, it’s now time to begin...

Deconstructing a Solidity Contract — Part II: Creation vs. Runtime

Let’s get started by attacking the disassembled gibberish of our contract with our divide-and-conquer lightsaber. As we saw in the introductory article, this disassembled code is very low-level...

Deconstructing a Solidity Contract —Part I: Introduction

You’re on the road, driving fast in your rare, fully restored 1969 Mustang Mach 1. The sunlight shimmers on the all-original, gorgeous plated rims. It’s just you, the road, the desert, and the never-ending chase of the horizon. Perfection!