14 releases (0 unstable)

new 28.9.0-non-semver-compat Jul 9, 2025
28.7.0-non-semver-compat Jun 30, 2025
27.5.2-non-semver-compat May 2, 2025
27.0.0-non-semver-compat Mar 21, 2025
26.7.0-non-semver-compat Mar 6, 2025

#690 in Magic Beans

Download history 101/week @ 2025-03-22 40/week @ 2025-03-29 75/week @ 2025-04-05 80/week @ 2025-04-12 140/week @ 2025-04-19 481/week @ 2025-04-26 542/week @ 2025-05-03 150/week @ 2025-05-10 29/week @ 2025-05-17 3/week @ 2025-05-24 128/week @ 2025-06-07 92/week @ 2025-06-14 97/week @ 2025-06-21 203/week @ 2025-06-28 346/week @ 2025-07-05

772 downloads per month
Used in 8 crates (via zksync_tee_prover_interfa…)

MIT/Apache

755KB
16K SLoC

ZKsync Era VM Interfaces

This crate declares interfaces used by all version of the ZKsync Era VM.

See also


lib.rs:

ZKsync Era VM interfaces.

Developer guidelines

Which types should be put in this crate and which ones in zksync_multivm or other downstream crates?

  • This crate should contain logic not tied to a particular VM version; in contrast, most logic in zksync_multivm is version-specific.
  • This crate should not have heavyweight dependencies (like VM implementations). Anything heavier than serde is discouraged. In contrast, zksync_multivm depends on old VM versions.
  • If a type belongs in this crate, still be thorough about its methods. VM implementation details belong to zksync_multivm and should be implemented as functions / extension traits there, rather than as methods here.

Which types should be put in this crate vs zksync_types?

  • In this case, we want to separate types by domain. If a certain type clearly belongs to the VM domain (e.g., can only be produced by VM execution), it probably belongs here. In contrast, if a type is more general / fundamental, it may belong to zksync_types.

Dependencies

~14–24MB
~306K SLoC