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

Make getting circuit version more stable #311

Closed
BGluth opened this issue Jun 21, 2024 · 3 comments · Fixed by #310
Closed

Make getting circuit version more stable #311

BGluth opened this issue Jun 21, 2024 · 3 comments · Fixed by #310
Assignees
Labels
crate: zero_bin Anything related to the zero-bin subcrates.

Comments

@BGluth
Copy link
Member

BGluth commented Jun 21, 2024

When we determine the version of serialized circuits that we should use for a given version of zero_bin, we use the version of evm_arithmetization that is set in Cargo.lock. This is perfect as a way to version serialized circuits, but the way we do this at runtime is not the best for distributing a binary for others to use.

Currently this is the process:

  • At compile time, we get the path to the root of the repo by reading the env variable CARGO_MANIFEST_DIR and bake this path into the binary.
  • At runtime, we look for Cargo.lock in this directory and attempt to read the version of evm_arithmetization.
  • If we can't find Cargo.lock or a version of evm_arithmetization inside the file, we default to the NA version.

While the above should work fine in development settings, this is probably going to be an issue once we start building and redistributing the zero_bin binary since it's going to attempt to look for Cargo.lock in the location that it was built in.

Ideally instead, if we can read the version set in Cargo.lock at compile time and bake the version string into the binary, this is probably the most optimal solution. However, doing this requires using a proc macro which (at the moment) requires a sub-crate that only contains proc macros and nothing else.

While we could create a sub-crate just for this, I also noticed that no crate exists for reading a project's Cargo.lock at compile time, which I find a bit surprising. When I have a bit of free time, I'm going to attempt to create a public crate to do this, since I think there are probably a lot of other projects that could also use this.

@BGluth BGluth added the crate: zero_bin Anything related to the zero-bin subcrates. label Jun 21, 2024
@BGluth BGluth self-assigned this Jun 21, 2024
@Nashtare Nashtare added this to the Cleanups and Misc. milestone Jun 21, 2024
@BGluth
Copy link
Member Author

BGluth commented Jun 26, 2024

Update: I'm going to take the time to write a generic library to query Cargo.lock at compile time. Might not be ready for a while, so the proper fix might take a bit.

@Nashtare Nashtare modified the milestone: Cleanups and Misc. Jun 27, 2024
@Nashtare Nashtare modified the milestones: Misc., System strengthening Jul 12, 2024
@BGluth
Copy link
Member Author

BGluth commented Aug 9, 2024

So I think we can close this issue once #310 is merged since it switches circuit versioning over to be kernel hash based.

@Nashtare
Copy link
Collaborator

Nashtare commented Aug 9, 2024

Agreed 👍🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crate: zero_bin Anything related to the zero-bin subcrates.
Projects
Status: Done
2 participants