Closed alxiong closed 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.
cc @dailinsubjam as this might also affect the QC integration work.
It should probably be a trait that can be applied to the actual stake table, yes...
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
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.
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.
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.
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?
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
.
Changes include:
trait QuorumCertificateValidation
->trait QuorumCertificate
struct BitvectorQuorumCertificate
->struct BitVectorQC
::parti_sign()
->::sign()
(consistent with hotshot spec)active_keys
->signers
CheckedType
as @nyospe pointed out that we don't need this.Proof
, and replace withQC
assemble()
andcheck()
to deal withSelf::QC
directly (consistent with Hotshot spec)trace()
API and tests