Closed sshine closed 1 week ago
Relates to #164
Workaround suggested: Make ConstraintGen
a public crate and use cargo public --allow-dirty
to publish it.
unassigning myself. I believe @sshine's supervision is needed to publish a new version of the crate with constraints baked in.
Fixed with #323.
Problem
In order to
.prove()
and.verify()
one must currently runcargo run --bin constraint-evaluation-generator
beforecargo build
. This overwrites some Rust files intriton-vm/src/
that currently contain stubs that panic. It is possible to.run()
and.simulate()
without panic, since constraint polynomials are not involved.This makes working on Triton VM a little annoying, but worse so depending on
triton-vm
as a 3rd-party library impossible:cargo
toolchainCurrent patchy solutions is to either:
triton-vm
to a public location, runcargo run --bin constraint-evaluation-generator
, commit the generated code on a throw-away branch, and addtriton-vm = { git = "that public location", branch = "a throw-away branch" }
triton-vm
locally and addtriton-vm = { path = "../triton-vm/triton-vm" }
Solutions
build.rs
script: Early experimentation suggested that there's a circular dependency problem: Theconstraint-evaluation-generator
crate depends ontriton-vm
, so depending on the generator intriton-vm
'sbuild.rs
creates the circular dependency. To remove the circularity, one would need for the constraint polynomials to live in a separate crate that does not depend ontriton-vm
, but I believe the coupling here is non-trivial to resolve. (The constraints are expressed in terms of things that relate to tables, so those types need to be abstract.)#[derive(...)]
that calls the constraint generator. Sinceconstraint-evaluation-generator
is pretty fast by now, this should come with very few downsides. We would need to releaseconstraint-evaluation-generator
on crates.io, though, perhaps under a name liketriton-constraints-macro
or such.