All the things I wish (native) Solidity would let me do
summary
OpenZeppelin’s v5.5 library contains 400 assembly blocks because lack of generics forces procedural codegen and proxies rely on inline assembly. Low-level calls and try/catch mis-handle non-contract addresses, `abi.encode` inside loops repeatedly advances the free-memory pointer so abi.encode in loops expands the free memory pointer, and calldata decoding requires memory allocation. Reverting with bubbled raw bytes and emitting panic codes both need assembly today — cannot bubble raw revert bytes — and unchecked blocks still perform array bound checks. Solidity Core and a standard library could address these.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:47Solidity needs assembly
- 2:51Low-level call limits
- 4:14Memory allocation issues
- 6:00Revert handling limits
- 7:21ABI decoding failures
- 8:27Panic codes and arithmetic
- 10:12Array bounds checking
- 12:01Memory buffer inefficiencies
- 13:05Transient storage limits
- 15:33Can Solidity Core help?
- 16:37Q&A
related talks
11mSolidity in 2023
25mCommSec D2 - Smart Contract (In)Security
21mScaffold-Eth, OpenZeppelin, and EVM Optimization
15mCompositional Verification of Smart Contracts Through Communication Abstraction
01h 31mHow to find Solidity vulnerabilities
21mPractical Verification Of Smart Contracts Using Memory Splitting
20mLearning How to Build Secure Smart Contracts
29mCompositional Verification of Smart Contracts Through Communication Abstraction