Vitalik Buterin said Fusaka’s main feature, PeerDAS, will let Ethereum nodes check and rebuild blocks without storing all the data. He spoke as the community prepares for the Fusaka upgrade on the Ethereum mainnet on Dec. 3.
The change aims to help Layer 2 scaling now, and possibly Layer 1 later, by letting nodes verify data availability with only small pieces of each block. Nodes do this by asking for random chunks and using erasure coding to fill in missing parts.
How is this important?
PeerDAS aims to cut the data burden on nodes. Instead of every node holding every byte, each node fetches a few chunks.
If more than 50% of chunks are known to be available, a node can then retrieve those pieces and recover the rest. That is the basic idea. It is meant to save space and make the network easier to run.
Also Read: Ethereum Core Developer “Safe and Free” After Reported Detention In Turkey
How the method works is simple in concept but new in practice. Nodes only request a small set of chunks. They check that those chunks are present, and if the sample looks good, they trust that the full block can be rebuilt using erasure coding.
Even if many actors are dishonest, the system can work around that by relying on at least one honest participant. Different nodes can handle the task for different blocks.
Developers plan future steps that will split these duties even more, with cell-level messaging and shared block building.
Safety is a core concern, as Buterin said the team is being cautious. This technology is new, and the core developers want to test it well. That is why blob counts will climb slowly at first. The plan is to grow capacity carefully over time, not to rush the change.
When is it coming?
The upgrade schedule is already set for test networks, and Fusaka will go to Holesky on Oct. 1, Sepolia on Oct. 14, and Hoodi on Oct. 28, and the mainnet target is Dec. 3.
The Ethereum Foundation also started a four-week audit contest on Sept. 15 to find bugs and push fixes before the code reaches mainnet. The contest aims to surface problems while there is time to fix them.
Local tests and the audit contest are designed to reduce risk, and core developers emphasise the importance of having many eyes on the code. They plan to run extensive tests and stage the rollout so that any issues are identified on testnets first. Developers will increase blob counts slowly, watch results, and adjust plans as needed.
What does it mean?
Community groups and node operators will watch how sampling performs in the field, and the system depends on probabilistic checks.
That means success comes from the combined checks of many nodes, not from absolute proof by one node. If sampling proves reliable, the approach could change how data availability is handled on Ethereum.
If PeerDAS works as planned, it may enable large improvements for Layer 2 systems that rely on the base layer for data availability. Over the longer term, and if L1 gas limits rise enough, the same ideas could help Layer 1 scale too.
For now, the team’s message is clear: move carefully, test widely, and only raise limits once the system proves safe.