EspressoSystems / hotshot-primitives

Primitives used in HotShot
https://hotshot-primitives.docs.espressosys.com/
3 stars 2 forks source link

Refactor QC traits #64

Closed alxiong closed 1 year ago

alxiong commented 1 year ago

Changes include:

alxiong commented 1 year ago

Another question I had is if we should turn struct StakeTableEntry into a trait that for StakeTable and describe its behavior. (maybe this trait should be inside crate::stake_table) because this struct is our imaginary struct and won't be the actual entry or stake table type. and to facilitate interfacing between QC code and StakeTable code, we just use traits following Hotshot spec's T.update, T.register etc.

cc @philippecamacho @nyospe @mrain

Will continue this work #65.

chancharles92 commented 1 year ago

cc @dailinsubjam as this might also affect the QC integration work.

nyospe commented 1 year ago

It should probably be a trait that can be applied to the actual stake table, yes...

philippecamacho commented 1 year ago

After rerunning the build, it failed. I also have an error on my machine.

> cargo test
error[E0432]: unresolved imports `jf_relation::gadgets::ecc::non_native`, `jf_relation::gadgets::EmulationConfig`
  --> src/circuit/qc_keyagg.rs:12:15
   |
12 |         ecc::{non_native::EmulatedPointVariable, Point, SWToTEConParam},
   |               ^^^^^^^^^^ could not find `non_native` in `ecc`
13 |         EmulationConfig,
   |         ^^^^^^^^^^^^^^^ no `EmulationConfig` in `gadgets`

error[E0432]: unresolved imports `jf_primitives::merkle_tree::hasher`, `jf_primitives::reed_solomon_code`
  --> src/vid/advz.rs:27:19
   |
27 |     merkle_tree::{hasher::HasherMerkleTree, MerkleCommitment, MerkleTreeScheme},
   |                   ^^^^^^ could not find `hasher` in `merkle_tree`
...
32 |     reed_solomon_code::reed_solomon_erasure_decode_rou,
   |     ^^^^^^^^^^^^^^^^^ could not find `reed_solomon_code` in `jf_primitives`

error[E0432]: unresolved import `jf_relation::gadgets::from_emulated_field`
   --> src/circuit/qc_keyagg.rs:154:40
    |
154 |         gadgets::{ecc::SWToTEConParam, from_emulated_field},
    |                                        ^^^^^^^^^^^^^^^^^^^ no `from_emulated_field` in `gadgets`

error[E0432]: unresolved import `jf_primitives::merkle_tree::hasher`
   --> src/vid/advz.rs:540:38
    |
540 |     use jf_primitives::{merkle_tree::hasher::HasherNode, pcs::checked_fft_size};
    |                                      ^^^^^^ could not find `hasher` in `merkle_tree`

error[E0603]: struct `RescueCRHF` is private
   --> src/circuit/qc_keyagg.rs:151:40
    |
151 |     use jf_primitives::rescue::sponge::RescueCRHF;
    |                                        ^^^^^^^^^^ private struct
    |
note: the struct `RescueCRHF` is defined here
   --> /home/philippe/.cargo-nix/git/checkouts/jellyfish-aebafe050ee5960c/77f7b12/primitives/src/rescue/sponge.rs:30:1
    |
30  | pub(crate) struct RescueCRHF<F: RescueParameter> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0603]: function `checked_fft_size` is private
   --> src/vid/advz.rs:540:63
    |
540 |     use jf_primitives::{merkle_tree::hasher::HasherNode, pcs::checked_fft_size};
    |                                                               ^^^^^^^^^^^^^^^^ private function
    |
note: the function `checked_fft_size` is defined here
   --> /home/philippe/.cargo-nix/git/checkouts/jellyfish-aebafe050ee5960c/77f7b12/primitives/src/pcs/mod.rs:304:1
    |
304 | fn checked_fft_size(degree: usize) -> Result<usize, PCSError> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0432`.
error: could not compile `hotshot-primitives` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
Some errors have detailed explanations: E0432, E0603.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `hotshot-primitives` (lib test) due to 6 previous errors
alxiong commented 1 year ago

After rerunning the build, it failed. I also have an error on my machine.

This is likely due to caching of cargo build in CI and failed to point to the right jellyfish version. The best way to solve it is version controlling Cargo.lock.

dailinsubjam commented 1 year ago

The type of message inputted to signing function is &GenericArray<A::MessageUnit, Self::MessageLength>, where type MessageLength = U32; so MessageLenth is bound with the length 32, is it possible to change it to a dynamic length? In hotshot the input data could be &[u8] with length 8 or 57.

chancharles92 commented 1 year ago

The type of message inputted to signing function is &GenericArray<A::MessageUnit, Self::MessageLength>, where type MessageLength = U32; so MessageLenth is bound with the length to 32, is it possible to change it to a dynamic length? In hotshot the input data could be &[u8] with length 8 or 57.

cc @philippecamacho for this question.

philippecamacho commented 1 year ago

The type of message inputted to signing function is &GenericArray<A::MessageUnit, Self::MessageLength>, where type MessageLength = U32; so MessageLenth is bound with the length to 32, is it possible to change it to a dynamic length? In hotshot the input data could be &[u8] with length 8 or 57.

We decided to only allow fixed length for the input of the signing function, meaning we expect the message to be some kind of commitment on the data.

@nyospe What is the the canonical way to compute a commitment over QC data in Hotshot?

dailinsubjam commented 1 year ago

The type of message inputted to signing function is &GenericArray<A::MessageUnit, Self::MessageLength>, where type MessageLength = U32; so MessageLenth is bound with the length 32, is it possible to change it to a dynamic length? In hotshot the input data could be &[u8] with length 8 or 57.

After today's discussion we plan to change the code in hotshot to make sure the commitment is of fixed size, no need to change in hotshot-primitives.