Skip to content

feat!: support key compression for storage diffs in pubdata#393

Open
antoniolocascio wants to merge 20 commits intoalocascio-prover-input-runfrom
alocascio-pubdata-compression
Open

feat!: support key compression for storage diffs in pubdata#393
antoniolocascio wants to merge 20 commits intoalocascio-prover-input-runfrom
alocascio-pubdata-compression

Conversation

@antoniolocascio
Copy link
Contributor

@antoniolocascio antoniolocascio commented Nov 12, 2025

What ❔

This PR introduces a modification to the pubdata format to support compression of keys. Previously, we published the full 32-byte key for every storage diff (account or general slot diff). Now we add a header for diffs, where we declare: total number of diffs, nb of initial account writes and nb of initial slot writes and index encoding length. After which, we publish all initial account writes, all initial slot writes and repeated writes. More details about the format can be found in the docs.

Why ❔

Is this a breaking change?

  • Yes
  • No

Checklist

  • PR title corresponds to the body of PR (we generate changelog entries from PRs).
  • Tests for the changes have been added / updated.
  • Documentation comments have been added / updated.
  • Code has been formatted.

@0xVolosnikov
Copy link
Contributor

0xVolosnikov commented Nov 12, 2025

Gains are not clear, but lgtm.
We also should include a general versioning for pubdata to simplify similar changes in the future: #395

@AntonD3
Copy link
Contributor

AntonD3 commented Nov 13, 2025

Btw, we may use similar approch we use in Era, like first diffs with compressed key, then with full - https://docs.zksync.io/zksync-protocol/rollup/pubdata-compression . It will probably be more efficient

@antoniolocascio
Copy link
Contributor Author

@AntonD3 I fixed the index to be variable length. As we discussed offline, it might be worth changing the format to group together (initial_account_write, initial_slot_writes, repeated_writes), but maybe we can do that later.

There's one thing that isn't clear to me tho. On Era, it seems like all repeated writes use the same length to encode the index. This means two things:

  1. It's not trivial (at least to me) to assess the tradeoff between not having the metadata byte vs taking the worst case.
  2. I also have no idea how zkos would compute the pubdata length in forward, if we require to know the largest index touched in a repeated write.

@github-actions
Copy link
Contributor

Benchmark report

Benchmark Symbol Base Eff Head Eff (%) Base Raw Head Raw (%) Base Blake Head Blake (%) Base Bigint Head Bigint (%)
block_19299001 run_prepared 311,545,073 311,279,697 (-0.09%) 268,595,985 268,330,609 (-0.10%) 410,610 410,610 (+0.00%) 9,094,832 9,094,832 (+0.00%)
block_22244135 run_prepared 191,678,402 191,465,025 (-0.11%) 164,523,630 164,310,253 (-0.13%) 172,020 172,020 (+0.00%) 6,100,613 6,100,613 (+0.00%)
precompiles bn254_ecadd 53,197 53,197 (+0.00%) 47,745 47,745 (+0.00%) 0 0 (+0.00%) 1,363 1,363 (+0.00%)
precompiles bn254_ecmul 731,034 731,034 (+0.00%) 566,846 566,846 (+0.00%) 0 0 (+0.00%) 41,047 41,047 (+0.00%)
precompiles bn254_pairing 72,689,618 72,689,618 (+0.00%) 58,161,474 58,161,474 (+0.00%) 0 0 (+0.00%) 3,632,036 3,632,036 (+0.00%)
precompiles ecrecover 484,255 485,918 (+0.34%) 314,099 315,126 (+0.33%) 0 0 (+0.00%) 42,539 42,698 (+0.37%)
precompiles id 933 933 (+0.00%) 933 933 (+0.00%) 0 0 (+0.00%) 0 0 (+0.00%)
precompiles keccak 137,578 137,578 (+0.00%) 137,578 137,578 (+0.00%) 0 0 (+0.00%) 0 0 (+0.00%)
precompiles modexp 32,084,944 32,084,944 (+0.00%) 21,427,124 21,427,124 (+0.00%) 0 0 (+0.00%) 2,664,455 2,664,455 (+0.00%)
precompiles p256_verify 754,238 754,238 (+0.00%) 473,914 473,914 (+0.00%) 0 0 (+0.00%) 70,081 70,081 (+0.00%)
precompiles point_evaluation 51,158,377 51,158,377 (+0.00%) 39,535,749 39,535,749 (+0.00%) 0 0 (+0.00%) 2,905,657 2,905,657 (+0.00%)
precompiles process_transaction 73,834,017 73,836,612 (+0.00%) 59,137,545 59,132,520 (-0.01%) 160 160 (+0.00%) 3,673,478 3,675,383 (+0.05%)
precompiles ripemd 8,028 8,028 (+0.00%) 8,028 8,028 (+0.00%) 0 0 (+0.00%) 0 0 (+0.00%)
precompiles run_prepared 148,139,597 148,134,296 (-0.00%) 118,668,941 118,652,652 (-0.01%) 5,070 5,070 (+0.00%) 7,347,384 7,350,131 (+0.04%)
precompiles sha256 13,167 13,167 (+0.00%) 13,167 13,167 (+0.00%) 0 0 (+0.00%) 0 0 (+0.00%)
precompiles verify_and_apply_batch 132,197 132,162 (-0.03%) 97,477 97,442 (-0.04%) 2,170 2,170 (+0.00%) 0 0 (+0.00%)

Base automatically changed from dev to main November 13, 2025 21:01
@0xVolosnikov 0xVolosnikov changed the base branch from main to dev November 13, 2025 21:34
@antoniolocascio antoniolocascio force-pushed the alocascio-pubdata-compression branch from 8029932 to 5a04a70 Compare December 1, 2025 11:29
@antoniolocascio antoniolocascio changed the base branch from dev to alocascio-prover-input-run December 1, 2025 11:36
@antoniolocascio antoniolocascio force-pushed the alocascio-pubdata-compression branch from 8768261 to 232d117 Compare December 1, 2025 12:05
@antoniolocascio antoniolocascio force-pushed the alocascio-prover-input-run branch 6 times, most recently from 1208ff0 to f94dc60 Compare February 6, 2026 10:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants