Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(vm): add gateway changes to fast vm #3236

Merged
merged 5 commits into from
Nov 12, 2024
Merged

Conversation

perekopskiy
Copy link
Contributor

What ❔

Ports VM changes to vm_fast that are needed for gateway version. Code changes are mostly copied from vm_latest

Why ❔

vm_fast should support new protocol version

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 via zkstack dev fmt and zkstack dev lint.

@perekopskiy perekopskiy marked this pull request as ready for review November 7, 2024 19:01
slowli
slowli previously approved these changes Nov 12, 2024
Copy link
Contributor

@slowli slowli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to unit-test pubdata logic in multivm? (I'd imagine by setting ProtocolVersionId to the gateway version.) AFAICT, pubdata-related fields are covered by shadow VM checks, so these tests could help checking that the relevant logic works identically for vm_latest and vm_fast. Can be done separately, of course.

core/lib/multivm/src/versions/vm_fast/version.rs Outdated Show resolved Hide resolved

// Save the pubdata for the future initial bootloader memory building
self.bootloader_state
.set_pubdata_input(pubdata_input.clone());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: clone() isn't necessary here.

Also, since pubdata_input is almost only read from the VM, so it could be relatively straightforward to return pubdata_input from this function (e.g., by supplying pubdata: Option<(&dyn PubdataBuilder, &mut PubdataInput)> to it), and then use it in finish_batch(). I'm not sure a similar transform would work for vm_latest though, and we'd probably want to keep BootloaderState equivalent for both (ideally, it'd make sense to share it).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed clone.
Not sure I understood the point for returning pubdata_input, can you elaborate on why is it better than storing and reading it from BootloaderState?

@perekopskiy
Copy link
Contributor Author

Would it be possible to unit-test pubdata logic in multivm?

Do you mean something particular? Rollup/Validium pubdata builders' logic is covered with tests in pubdata_builders module. We also have a vm test in sync-layer-stable that checks pubdata_inputs more thoroughly, it will be merged to main soonish.

@perekopskiy perekopskiy added this pull request to the merge queue Nov 12, 2024
Merged via the queue into main with commit f3a2517 Nov 12, 2024
33 checks passed
@perekopskiy perekopskiy deleted the support-gateway-in-vm-fast branch November 12, 2024 17:13
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