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

Incorrect Handling of Columns in Different Perspectives with the Same Name #312

Open
DavePearce opened this issue Jan 12, 2025 · 2 comments
Labels
bug Something isn't working

Comments

@DavePearce
Copy link
Collaborator

DavePearce commented Jan 12, 2025

This turns out (as far as I can tell) to be a fairly serious bug. The issue is that columns with the same name, but defined in different perspectives always compile down to the same column. That is particularly a problem when they have different types (e.g. one has binary@prove for example) since the most restrictive type will be applied to all. Example to illustrate:

(defcolumns
    A
    (P :binary@prove)
    (Q :binary@prove))

(defperspective p1 P ((B :binary@prove)))
(defperspective p2 Q ((B :byte)))

(defconstraint c2 (:perspective p2) (vanishes! (* A B)))

The question here is which column B refer to in the constraint c2? Here is the wizard-iop output:

func ZkEVMDefine(build *Builder) {
        _prelude___A := build.RegisterCommit("A", build.Settings.Traces.Prelude)
        _prelude___B := build.RegisterCommit("B", build.Settings.Traces.Prelude)
        _prelude___B := build.RegisterCommit("B", build.Settings.Traces.Prelude)
        _prelude___P := build.RegisterCommit("P", build.Settings.Traces.Prelude)
        _prelude___Q := build.RegisterCommit("Q", build.Settings.Traces.Prelude)

        build.GlobalConstraint("B-binarity", _prelude___B.AsVariable().Mul(symbolic.NewConstant("1").Sub(_prelude___B.AsVariable())))
        build.GlobalConstraint("P-binarity", _prelude___P.AsVariable().Mul(symbolic.NewConstant("1").Sub(_prelude___P.AsVariable())))
        build.GlobalConstraint("Q-binarity", _prelude___Q.AsVariable().Mul(symbolic.NewConstant("1").Sub(_prelude___Q.AsVariable())))
        build.GlobalConstraint("c2", _prelude___Q.AsVariable().Mul(_prelude___A.AsVariable().Mul(_prelude___B.AsVariable())))
}

Notice how there is only a single column B which includes a binarity constraint. This is not consistent at all with the intention of the original code. However, we can agree that the original code should never have compiled in the first place.

@DavePearce DavePearce added the bug Something isn't working label Jan 12, 2025
@OlivierBBB
Copy link
Collaborator

OlivierBBB commented Jan 13, 2025

I think we consistenly use the fully qualified names e.g.

(defconstraint c2
     (vanishes! (*  p2.A  p2.B)))

How does this affect your observation (if at all) ?

@DavePearce
Copy link
Collaborator Author

How does this affect your observation (if at all) ?

This doesn't prevent the bug at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants