Parameterize programs #100
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit introduces a bunch of changes to the map types WitnessTypes and WitnessValues. Instead of splitting these changes into a dozen commits, I combined them all into one commit. The goal of these changes is to make WitnessTypes and WitnessValues more ergonomic to use. Move WitnessTypes into witness.rs. Use HashMap instead of BTreeMap for better asymptotics. I used to require a sorted list of keys, but that is no longer the case. Make both WitnessTypes and WitnessValues immutable. Instead of building a mutation API for these maps, we can simply construct a HashMap with its rich API. All values of HashMap<WitnessName, ResolvedType> are valid for WitnessTypes and similarly for WitnessValues. Wrap the inner map in an Arc<T> for cheap cloning. This means that we can pass owned WitnessValues, which simplifies some code. Wrap the implementation of WitnessTypes and of WitnessValues inside macros, so we can reuse the code for other kinds of maps. I will add Parameters and Arguments, which will use these macros.
Allow for different kinds of modules that each define a list of
constants. Each module has a name, such as the witness module.
Currently the only module is `mod witness { ... }`. In the following
commits, we will add a `mod param { ... }` module for defining
commitment-time values such as public keys.
Most changes in this commit are renamings or moved code.
Many Simfony programs differ only in hardcoded values such as public keys. This commit introduces parameters of the form `param::PUBLIC_KEY` which can be used as variables that resolve to a Simfony value at commitment time. Simfony programs with parameters are templates which can be instantiated as concrete Simfony programs by providing arguments for the template's parameters. CompiledProgram::new(s, Arguments::default()) can be used to parse and compile a Simfony program without parameters. However, I expect most programs to contain parameters. It remains an open question if parameters are a good abstraction for this use case. If they turn out as not useful, we can remove them. I had to adapt the fuzz tests to handle arguments. Interestingly, we can use simfony::ArbitraryOfType to create a random list of arguments for a given list of parameters. Very nice!
Extend the unit test and integration test harnesses to handle parameterized programs. Parameterize the public key value in the P2PK example.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor the code that handles witness types / values / modules. Add parameterized values to Simfony which are instantiated at commitment time.
Simfony programs with parameters are templates for a family of Simfony programs. A template is instantiated by providing arguments to its parameters. Arguments can be provided via JSON or via code
mod param { ... }.The existing API needed to be updated to handle parameters. This turned out to be more work than expected :) While most changes are mechanical, there were some interesting engineering problems, such as handling parameters inside fuzz tests.