Fusaka hard fork
Osaka (execution) + Fulu (consensus) · Mainnet 2025-12-03
PeerDAS, where nodes verify a sample of blob data instead of downloading all of it, greatly expanded the data space available to L2s. BPO forks, which raise only the blob count, widen that space in steps afterward.
What changed
- Users
- Everyday transactions use far less gas than the new gas cap, so they keep working as before. There are few directly visible changes, but wallets that let you use an account through familiar methods such as a smartphone's secure chip and fingerprint or face recognition, instead of a seed phrase, became possible. Apps that make heavy use of the newly added CLZ instruction see lower computation costs.
- Wallet & app developers
- A P256VERIFY precompile was added at address 0x100, so secp256r1 signatures used by smartphone secure chips and WebAuthn devices can be verified onchain for 6900 gas. This makes passkey-based wallets and account abstraction easier to implement. The gas a single transaction can use is capped at 16,777,216, so tools and dapps must reflect the cap, and deployments of large contracts that exceed it must be split across multiple transactions. Senders of blob transactions must compute the cell proofs themselves and respect the limit of 6 blobs per transaction. The new CLZ instruction also reduced gas for math libraries and bitmap code.
- L2
- With PeerDAS, where nodes check only a sample of the blob data, the layer 1 data availability space, which had been the bottleneck, grew substantially. From here on, the space will be widened step by step through small BPO forks that change only the blob count. Rollups now have ample room to post data, which lays the groundwork for higher throughput. Thanks to the new CLZ instruction, zero-knowledge proof systems prove a native instruction instead of an expensive dynamic shift, which lowers proving costs. P256VERIFY has the same interface as RIP-7212, which was deployed first on L2s, so existing contract bytecode works unchanged, but the gas cost is 6900 rather than 3450.
- Node operators
- Nodes do not download and store all the blob data. They store only the columns assigned to them according to their own node ID. Every slot they receive samples from peers to check that the data was actually published. A node running validators must store more data than an ordinary full node, and this requirement grows in proportion to the number of validators it is responsible for. The block gas limit can be kept higher than the transaction gas cap, and as long as each individual transaction in a block respects the cap, the block is processed as is.