Skip to content

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

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

aszepieniec
Copy link
Contributor

Rebases #121 onto master. Updates dependencies.

Sword-Smith and others added 11 commits May 6, 2025 10:52
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.
Copy link
Member

@jan-ferdinand jan-ferdinand left a 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 {
Copy link
Member

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();
Copy link
Member

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
}

Copy link
Contributor Author

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.

Copy link
Member

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. 😌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants