-
Notifications
You must be signed in to change notification settings - Fork 12
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
Initial Rust implementation #174
base: master
Are you sure you want to change the base?
Conversation
The files are intended to be compared side-by-side with the C++ implementation. E.g., script.rs first contains definitions from script.h, followed by definitions from script.cpp. |
629eed7
to
e95972b
Compare
The only changes here other than moving chunks of code around are - moving `evaluate` out of `impl Script`, which required changing `&self` to `script: &Script`; and - unifying `ExecutionOptions` with `VerificationFlags`.
For easier side-by-side comparison.
848ebaa
to
09ac96b
Compare
The C++ impl uses exceptions for `ScriptNum`, but catches them.
These tests run both the C++ and Rust impls. One uses completely arbitrary inputs, and the other limits script_sig to data pushes.
For now, the underlying errors are discarded when comparing against the C++ results, but there are corresponding changes on the C++ side in a separate branch.
09ac96b
to
4c34b3e
Compare
I don’t know why the test suite is failing on the C++ side now.
My only guess is that it is somehow caused by the secp256k1(_sys) dependency maybe forcing a different version of the underlying Since there’s a lot of noise in the logs, here’s the actual error:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flushing comments; reviewed up to 336d0fe
src/interpreter.rs
Outdated
// Data is being pushed to the stack here; we may need to check | ||
// that the minimal script size was used to do so if our caller | ||
// requires it. | ||
if options.contains(VerificationFlags::MinimalData) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nonblocking: This is not a pure move; ideally this change would be split out into a separate commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean because it’s not a const
with bitwise ops?
I can push this to a later PR and swing VerificationFlags
back to a bunch of const
s. I think I just wrote this bit before I decided to stick as close to the C++ as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. This is because of the commit it’s in, which is intended to just rearrange @ebfull’s implementation a bit.
src/interpreter.rs
Outdated
// of a standard tx rule, for example) they can | ||
// enable `discourage_upgradable_nops` to turn | ||
// these opcodes into errors. | ||
if options.contains(VerificationFlags::DiscourageUpgradableNOPs) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
src/interpreter.rs
Outdated
if !options.contains(VerificationFlags::CHECKLOCKTIMEVERIFY) { | ||
if options.contains(VerificationFlags::DiscourageUpgradableNOPs) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
src/script_error.rs
Outdated
pub enum ScriptError { | ||
Ok = 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how big of a deal this is, but it might be better to be explicit about the exact binding to the C++ enum reprs for all of the cases; a reordering could accidentally cause these to get out of sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only reason for having the repr
is for the C++/Rust comparisons, where the C++ errors get mapped to the Rust ones. If they get out of sync, the tests should fail.
It works on Rust 1.81 but it doesn't on 1.82. Which is super weird, but should give you a direction where to investigate |
- remove `uint256` module - create a specific type for the C++/Rust comparison implementation - rename some identifiers - rephrase some comments
Thank you for your work on this so far @sellout! Are you planning to continue working on this one? We were hoping to tag a new release of |
7e16a5f
to
3b81cf5
Compare
- Switch from `log` to `tracing` for `warn!`, - Export `SignedOutputs`, which is needed to create a `HashType`, and - Upgrade zcash_primitives to the same version used by zebrad.
3b81cf5
to
f215757
Compare
Yes, sorry – until I saw your comment, I didn’t realize this branch wasn’t up-to-date with my current work (I had accidentally been pushing to my fork). I’ve updated it, fixing the merge conflicts, etc., but it still seems to have the test-building issue on Ubuntu. I’ll dig into that tomorrow. Also, this PR still needs some review. If anyone on the ZF side (@conradoplg, @arya2, whoever) has time to give it a go, I’m happy to facilitate that however I can. |
Matches the one in Zebra, although I think pinning to a specific release (e.g., `channel = "1.82"`) would help with consistency, perhaps avoiding issues like ZcashFoundation#174 (comment)
Ok, the current failing checks are failing on master (because of Rust stable toolchain changes that happened since those commits were merged), so #176 is trying to address those independently of this massive PR. |
* Add a basic rust-toolchain.toml Matches the one in Zebra, although I think pinning to a specific release (e.g., `channel = "1.82"`) would help with consistency, perhaps avoiding issues like #174 (comment) * Remove redundant toolchain info from GH workflow [actions-rs/toolchain doesn’t support TOML-formatted rust-toolchain files](actions-rs/toolchain#126), but it’s unnecessary anyway. - actions-rs/cargo will pick up the rust-toolchain.toml, so we usually don’t need to mention the toolchain at all; - the Windows build just runs `rustup target add x86_64-pc-windows-msvc` directly; and - where we want to build with multiple toolchains (in a matrix), there are some slightly-awkward conditionals. This also makes some other changes: - `fail-fast` is disabled because it hides useful & distinct build results; and - `rustup component add` for clippy and rustfmt are removed because they’re in the rust-toolchain.toml toolchain, and we want to make sure they are, so that they’re available to developers. * Pin rustup channel to "1.81" Newer versions until 1.85 (current nightly) have some breakage wrt C++ linking. * Have bindgen target correct rustc version It should match the version in rust-toolchain.toml. Unfortunately, it’s not possible to reference that directly, so this adds comments to remind contributors to update them together.
This provides two more implementations of the
ZcashScript
trait. One is a pure Rust implementation and the other runs both the C++ and Rust implementations, returning the C++ result and logging a warning if they differ.This follows the C++ implementation extremely closely for ease of initial review. Future changes will move from this to a Rustier approach.
E.g.,
if
instead ofmatch
It differs from the C++ in some places, as well. Numeric types and casting/From are changed in some places to avoid partiality. Also, the Opcodes are partitioned into multiple types because we eventually want to be able to enforce
push_only
at the type level, andPushValue
operations carry data (although not yet in the structure), which makes them distinct from operations (PushdataBytelength
, in particular).Footnotes
accesses generally return in
Result
, so?
ensures they’re safe, but we keep the bounds checking so that the stack state matches the C++ version (e.g., without the bounds checking, an op that pops two elements off the stack could fail after popping one, which would leave the stack in a different state than the C++ impl which checks the length of the stack before popping either). ↩