Skilled Professional (most days). Defends against the bad guys.
Joined September 2006
- Tweets 3,629
- Following 1,261
- Followers 12,211
- Likes 30,744
569 Photos and videos
Pinned Tweet
May 7
The first is simple, but it's 22 bytes of bytecode long.
Here's an illustration I made of four different ways to clean up an ethereum address using opcodes on the EVM stack machine.
1
28
2,462
Jun 4
Here's how to cheaply store 127kb accessible over RPC, with only a single bytes32 storage slot.
1. Put your data in transaction calldata, send it
2. Store the transaction hash in a bytes32
3. eth_getTransaction(txHash) to read
3
2
41
4,918
Jun 3
1. It is simple in theory to write a bug free smart contract: just make a list of every possible state and check that each is correct.
2. Since that gets rapidly hard as the code gets bigger: write simple code so there are fewer states to check.
1
3
29
1,381
May 28
I've submitted 3 small PR's to solidity that speed via-ir compilation up about 11%.
It's fun to learn about the insides of the compiler we all use, so let's tour each speed up. 1/7
7
10
102
12,163
May 28
Both YUL and regular compilation have a list of optimizes they run over the code to make better bytecode.
The slowest of these is dead code code elimination. This walks an AST, checking to see if it has been found already, and marking everything new that it finds.
1
9
533
May 28
Unfortunately, to lookup and record what has been found or not, it uses a growing red black tree - a tree of pointers that requires moving through the tree to find or add elements. This gets slow when you are doing it for every node of your compile AST for every time you want to analyze your code.
Changing this to a to be a hash lookup, with roughly constant time lookups and writes, and speeds up compilation by about 5%.
1
18
460
May 27
May 26
NTSB is investigating the May 26 crash of a Fokker DR 1 airplane in Frankston, TX.
1
543
May 26
In the spring of 2026, secure crypto development requires at least 4 computers per person.
Work computer has no npm, no VS code, no agents. I work on code on remote machines over ssh.
3
3
51
3,420
May 17
I wrote safety critical industrial code in the past, and the rhythm felt about the same as writing perfect DeFi code. Correctness is hard work anywhere.
I think the biggest difference on the EVM is the constant resource constraints. The solidity compiler is inefficient, but most of the real constraints are from the EVM design and that the most basic operations on ethereum during it's heyday were so brutally expensive that you were forced to design for both correctness and simultaneously do stunts for gas efficiency.
You can't currently hand an average programmer solidity evm ethereum and not have critical bugs as the output. Now that may be true for most critical systems, but there are bug classes that could be removed at the compiler level and we should do this.
A month ago I realized that everything I took as concrete - Solidity, the EVM, how the blockchain works - could actually be changed. My biggest personal pain in solidity/evm was contract size limitations, so yesterday I worked on a Solidity PR that makes a 3% reduction in bytecode size.
May 17
Beyond policy, I feel like the two meta-problems that have slowed our industry down the most:
- Solidity. Shipping truly safe code on EVM is brutally slow.
- Talent attractiveness. Deep technical talent doesn't want to work in crypto. They don't see the impact they could create, they only see speculation. We've failed to make the substance of the work legible to people who could move the frontier.
9
7
76
8,792
May 8
In the era of "the protocol functioned exactly as expected" postmortems after hacks, it's refreshing to see a clear eyed postmortem and an interesting bug too.
May 8
We have made the huff router source code that was exploited this week available, along with a postmortem on GitHub here:
github.com/EkuboProtocol/huf…
Please be patient while we work on next steps. We intend to propose a resolution plan to the DAO next week. This is the last tweet.
2
4
34
4,201
May 5
Beyond the fact that anyone who approves this code will get drained (never let the world control both the to and the from address for funds) here's how I would have written this example code in classic solidity:
May 5
Here's `PaymentHandler` in Classic Solidity. The struct holds every field that any variant could need.
Each branch of `processPayment` then manually validates which fields are meaningful for the active variant before doing the transfer.
6
4
42
6,038
May 5
The overarching style difference between the two approaches is that one provides a lot of ways to provide invalid data then spends a lot of code checking that you didn't enter the fields wrong, while mine eliminates extra inputs and anything the caller provides is either going to work or fail.
5
508
Apr 29
If you had the option of making all new solidity contracts 10% smaller, but cost 15 gas more to call, would you do it?
62%
10% smaller code, 15 gas
15%
Keep it the same!
23%
I don't care!
13 votes • Final results
4
2
936
Apr 20
The lesson from this weekend is:
1. Do not build a system like this
2. If you have built a system like this, fix it
3. If you depend on someone who depends on something like this, be scared, don't trust as much.
5
17
128
20,832
Apr 20
To add nuance, there's some aspect of this in any bridge. But trust should not be binary - you can't build a system like this on pure trust of the component before it.
1
6
1,207
Apr 20
I think many non-pure onchain projects may have something like this buried inside.
For example, a large restaking protocol might build a cron job that loads in the total amount staked over RPC, and then updates the onchain token's assets and distributes yeield with the results.
1
5
1,076