-
Notifications
You must be signed in to change notification settings - Fork 2
Asz/thv/root from auth struct #155
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
base: master
Are you sure you want to change the base?
Conversation
Add stub for calculating a Merkle root from an authentication struct. Also adds code to generate the witness. Cf. Neptune-Crypto/twenty-first#228
…of leafs When calculating the root, don't allow the list of leafs to be empty. We think we never need the snippet with those inputs, so that should be fine. It makes the initialization of the `t` value (that should end up containing the root) simpler, as we can do: ```rust let mut t = indexed_leafs.first().unwrap().1; ``` instead of ```rust let mut t = auth_struct .first() .copied() .unwrap_or_else(|| indexed_leafs.first().unwrap().1); ``` Code works with sane test.
Make Rust-shadowing and state initialization nicer.
Instead of storing this value to memory in each loop iteration, we just calculate it from `t: Digest` when we need it.
…x, not parent_index It's a bit more performant to store `left_index` on the stack and then calculate from it `parent_index` and `right_index` then to store `parent_index` as we did before and calculate the left and right index from that.
In a mutator-set context for which this is developed, the leaf-indices will be grouped together. The benchmark now reflects that.
Also: adapt `StaticAllocation` to reflect new conventions.
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 haven't reviewed the two big files root_from_authentication_struct.rs
and authentication_struct/shared.rs
yet.
|
||
/// Count the number of non-leaf nodes that were inserted *prior* to | ||
/// the insertion of this leaf. | ||
pub fn non_leaf_nodes_left(leaf_index: u64) -> u64 { |
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 assuming this function relates to Merkle Mountain Ranges, but neither function name nor comment communicate this.
- This function is neither used nor tested.
- If I understand the purpose of this function correctly, the entire body can be replaced by
num_leafs_to_num_nodes(leaf_index) - leaf_index
|
||
fn code(&self, library: &mut Library) -> Vec<LabelledInstruction> { | ||
let alpha_challenge_pointer = library.kmalloc(EXTENSION_DEGREE as u32); | ||
let alpha_challenge_pointer_write = alpha_challenge_pointer.write_address(); |
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.
nit:
- The return value of
kmalloc
is not a pointer (anymore), but a static allocation. - Many of the
*_{read, write}
variables are used exactly once, meaning their declaration could be omitted, resulting in less clutter and better readability of the assembly, in my opinion.
For example, the allocations could be used like:
triton_asm!{
push {alpha_challenge_alloc.write_address()}
write_mem {alpha_challenge_alloc.num_words()} // no repetition of allocation size
pop 1
}
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 disagree that
write_mem {alpha_challenge_alloc.num_words()}
is more readable than
write_mem {EXTENSION_DEGREE}
. The former is arguably less error-prone, but if we are optimizing for that objective then we should implement StaticAllocation::read
and StaticAllocation::write
which emit tasm code to accomplish what the function names suggest.
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.
That's a cool idea. It's probably what the StaticAllocation
methods are used for almost exclusively anyway. That said, I don't feel strongly about the initial comment of this thread. 😌
Co-authored-by: Ferdinand Sauer <[email protected]>
Rebases #121 onto master. Updates dependencies.