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

Define and apply a zksolc version support policy. #759

Open
elfedy opened this issue Dec 2, 2024 · 1 comment
Open

Define and apply a zksolc version support policy. #759

elfedy opened this issue Dec 2, 2024 · 1 comment
Assignees
Labels
compiler 📟 Issues specific to compiling feature ➕ Feature item needs triage ♟️ Issue needs to be picked up or assigned p1 🟠 Indicates high priority item

Comments

@elfedy
Copy link
Contributor

elfedy commented Dec 2, 2024

Component

Forge

Describe the feature you would like

Right now we do not have any policy regarding what zksolc versions does Foundry support, but we've been informally just supporting the latest release. This mean that our inputs and outputs only represent said release and may break and cause unexpected behavior for previous versions. An example of this is #737 that happened when we moved to zksolc 1.5.7 and switched getting bytecodes on eravm field vs evm field form the compiler output. These type of bugs cause bad UX, so we should give users some clarity of what to expect when using different versions of zksolc.

We should:

  • Define what versions we DO support and if we will implement a deprecation policy (i.e: if supporting a version means supporting it forever or if we will deprecate older versions as newer ones come in).
  • Implement that policy, which should consist at least of:
    • Making input/output aware of the zksolc version used when being serialized/deserialized. We may need to maintain several input/output data structures each corresponding to a version.
    • When using an unsupported version showing either an error or a warning to the user about it.
    • Having a test suite to ensure all supported versions work properly.
    • Have proper documentation about the defined version support policy.

Additional context

May deprecate: #639

@elfedy elfedy added compiler 📟 Issues specific to compiling feature ➕ Feature item needs triage ♟️ Issue needs to be picked up or assigned labels Dec 2, 2024
@hedgar2017
Copy link

hedgar2017 commented Dec 3, 2024

Hey @elfedy, thanks for raising this.

I was going to give the quick answer: We shall support all versions since Foundry was shipped to users.
However, I realised that Foundry had been shipped much earlier in somewhat raw shape to projects such as AAVE when zksolc was at its version v1.5.1 or so.

I propose keeping backward compatibility with zksolc v1.5.6 and not supporting the structures of v1.5.5 and earlier.
On v1.5.6, zksolc keeps its structures compatible. For instance, it still writes build artifacts to both evm and eravm, and will continue to do so.

Unfortunately, I cannot make up any comprehensive deprecation policy yet, as we have no telemetry for version usage.

Let's fix our support at zksolc v1.5.6 for now. Please make sure that Foundry works with both v1.5.6, v1.5.7, and upcoming v1.5.8 with the post-compile-time linkage support that is now being tested by Francesco.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler 📟 Issues specific to compiling feature ➕ Feature item needs triage ♟️ Issue needs to be picked up or assigned p1 🟠 Indicates high priority item
Projects
None yet
Development

No branches or pull requests

3 participants