Estimate ZKsync publication footprint for repeated storage writes
A state-diff rollup publishes the resulting storage changes for a batch. Multiplying the number of writes by one full storage slot can greatly misstate the amount of published data.
Compare one hot key with several new keys
The example repeatedly changes one slot inside the same batch. Contrast it with three writes to three previously unused slots. Even when application execution performs three writes in both cases, the resulting set of changed keys differs.
one batch: slot S changes 10 → 11 → 12 → 13
final state difference for S: 10 → 13
Use the batch boundary when computing a final-state footprint. The same writes split across separate batches can require separate state differences. Key enumeration and value compression also affect serialized size.
Separate publication footprint from a user fee quote
Execution still performs work for every write. Per-transaction accounting, refunds and other published items such as code or L2-to-L1 messages affect fees. Use a real transaction estimate rather than promising a fixed saving from the count of unique keys. docs.zksync.io ZKsync documentation