-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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): Extract VM interface to separate crate #2638
feat(vm): Extract VM interface to separate crate #2638
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The changeset stats look monstrous, but most files just have imports changed.
- I plan to try moving some VM-related types from
zksync_types
andzksync_utils
intozksync_vm_interface
in a follow-up PR; this one is large as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Glad you managed to extract it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot even express how happy I am to see that change, thank you! ❤️
I love the fact that traits from zksync_state
were moved to the new crate. If I don't miss anything, probably it means that era-test-node
no longer will have to depend on zksync_dal
(which was a shame, given that it doesn't use Postgres in any way), so the benefits here expand beyond this repository :)
If we think about further steps here, I have the following thing in mind:
We probably should prepare abstractions to extract execution_sandbox
from the API. I have a feeling that the abstraction for VmBootstrap
I proposed in the comment may be a significant chunk of work here. If it will encompass stuff like loading system contracts, then using historical/playground system contracts in the API should work out of the box. This will be a path towards having a single interface for the VM instead of 3.5 (state keeper/vm runner, API, era_test_node) and help with (currently somewhat ugly) implementation of eth_call
in the consensus module.
🤖 I have created a release *beep* *boop* --- ## [16.4.0](prover-v16.3.0...prover-v16.4.0) (2024-08-16) ### Features * Bump harness & gpu deps ([#2634](#2634)) ([2a7d566](2a7d566)) * Poll the main node API for attestation status - relaxed (BFT-496) ([#2583](#2583)) ([b45aa91](b45aa91)) * **vlog:** Report observability config, flush, and shutdown ([#2622](#2622)) ([e23e661](e23e661)) * **vm:** Extract VM interface to separate crate ([#2638](#2638)) ([cb9ac4e](cb9ac4e)) * **vm:** Fast VM integration ([#1949](#1949)) ([b752a54](b752a54)) ### Bug Fixes * Bump prover dependencies & rust toolchain ([#2600](#2600)) ([849c6a5](849c6a5)) * **prover:** Fix NWG ([#2590](#2590)) ([9b58ae9](9b58ae9)) * **prover:** Updated README.md ([#2604](#2604)) ([be9f357](be9f357)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
What ❔
zksync_multivm
crate by extracting its interface part into a separate crate.zksync_state
/zksync_multivm
uses in the workspace.Why ❔
multivm
dependency onzksync_state
, which is quite heavyweight (depends onsqlx
,rocksdb
etc.).Checklist
zk fmt
andzk lint
.