Add VRF proof verification / generation to the Schnorrkel wrapper - #2
Conversation
turns out, this task was left behind from the original source as a single-target build subtask to automatically detect the target currently being built for, but our fork targets multi-platform users, so we need all the target architecture builds
|
[KNOWN ISSUE] Build automation is broken. The original Unfortunately, compilation for all target architectures must happen manually in a similar way as described above, before officially "deploying a new version" for multi-arch usage. Is it worth investing effort into polishing the automation...? [RESOLVED]: Discussed with @georg-getz, polishing the automation is not worth it for now, as priorities are different. This goes into |
9c1b958 to
7c267be
Compare
dubbed too inconvenient as a public API method since java doesn't provide a u64 type, so the correct representation is left to the caller
add a sensible differentiation between "false" as "incorrect proof" and when an exception must be thrown in Java
add proper explanations for weird decisions in the respective places
useful to link rust source to a cargo.toml for VSCode users
no need to explicitly disable it as a default feature... for now
- remove semicolons; - simplify boolean expressions
No description provided.