-
-
Notifications
You must be signed in to change notification settings - Fork 812
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
this commit adds several output formats to aid with build reproducibility and source code verification: - `-f archive` - `-f solc_json` - `-f integrity` - `--base64` `-f archive` creates a "vyper archive" using the zipfile format. it emits the metadata associated with the build (settings, search path, compiler version, integrity hash) in the `MANIFEST/` folder inside the archive. `--base64` is only usable with `-f archive` and produces a base64-encoded archive (which is easier to copy-paste). both the base64 and binary versions of the archive round-trip. that is, if you provide an archive directly to the vyper compiler (e.g. `vyper contract.zip` or `vyper contract.zip.b64`), it should produce exactly the same output as running `vyper contract.vy` on the local machine with the same settings+environment that produced the archive. `-f solc_json` is for compatibility with standard json that a lot of verifiers and tooling currently uses. it uses the same "output bundle" machinery as `-f archive`, but spits out in "standard-json" format (consumable by `--standard-json`). both of these use an `OutputBundle` abstraction, which abstracts collecting the inputs to the build. these include - settings (whatever is on the Settings object) - search path - compiler version - integrity hash importantly, `OutputBundle` recovers and anonymizes search paths used during compilation. this is done to minimize leaking of user information in archives. however, it comes with a tradeoff -- because of how the anonymization works, it is possible to have a build where search paths are not recoverable (specifically, if a module "escapes" its package with too many `..`, the resulting anonymized path will be bogus). several methods were tried to prevent this, but in the end this method was chosen, which prioritizes minimizing leakage over handling edge cases. `-f integrity` produces an "integrity hash", which is basically a checksum over the source file inputs. it is intended to let consumers of the compiler know when any input in the dependency tree has changed and recompilation is necessary. it is conservative by design; it works by recursively hashing source text as opposed to AST or any other semantic representation of source code. it can also be used by tooling as a check to determine if the source tree in an archive is the same as expected. this would likely be an additional check in addition to bytecode comparison, since there could differences in source code (e.g. comments) which affect the integrity hash but not the bytecode. the integrity hash computation currently depends on all frontend analysis to complete. in theory, since it only depends on source code, it could be refactored into another preliminary pass in the compiler, whose sole job is to resolve (and hash) imports. however, it would be additional maintenance work. we could revisit if the performance of this method becomes reported as an issue (note: current numbers are that this method operates at roughly 2500 lloc per second). currently, there are two places where build reproducibility might fail - in checking the integrity hash of an archive or during archive construction itself (if there is a compile-time failure, this could happen for example if the user is trying to send a reproduction of an error). it was decided that the most user-friendly thing to do is to emit a warning in these cases, rather than adding additional compilation flags that control whether to bail out or not. the tentative canonical suffix for vyper archive (the zipfile version) is `.vyz`, although this is subject to change (several alternatives were also considered, including `.den` - as in "a den of vypers"!).
- Loading branch information
1 parent
3af5390
commit 75c75c5
Showing
20 changed files
with
869 additions
and
137 deletions.
There are no files selected for viewing
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 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 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 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
Oops, something went wrong.