Skip to content

Conversation

@Al-Kindi-0
Copy link
Collaborator

Describe your changes

Closes #467
Also includes #257

Checklist before requesting a review

  • Repo forked and branch created from next according to naming convention.
  • Commit messages and codestyle follow conventions.
  • Commits are signed.
  • Relevant issues are linked in the PR description.
  • Tests added for new functionality.
  • Documentation/comments updated according to changes.
  • Updated CHANGELOG.md

@Al-Kindi-0 Al-Kindi-0 force-pushed the al-hasher-constraints branch from cb48f93 to 3290e8e Compare October 3, 2025 09:11
Copy link
Contributor

@adr1anh adr1anh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave it another pass focusing on the actual constraints. I'm still confused about the overall constraints, even with the docs.

While I haven't fully thought things through, I think it would help if we state the constraints we apply at

  • first row
  • transition rows
  • penultimate row
  • last row


# Enforce that if any of f_abp, f_mpa, f_mva, f_mua flags is set to 1, the next value of s[0]
# is 0.
enf s[0]' * f_comp = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, if we're in the last row of an operation which carries over to the next block, then the next row (which is the first of the next block), we must perform an output?

I think I see now though. We're indicating with s[0] that this is a block in which we will output the value when we reach the end?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, if we are outputting a result in the current row then the next row should be the start of a new operation, which implies that s[0] must be 1 (note that s[0] partitions the hasher ops into two groups with the 1 group consisting of output ops).
If, on the other hand, the op of the next cycle is one of the absorption ops (which happen on rows 1 less than multiples of 8) then the s[0] in the next row (which is a multiple of 8 row) is set to 0 so that we prohibit any op which starts a (new) computation.

Copy link
Contributor

@adr1anh adr1anh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. We'll definitely need another more thorough audit of the actual contraints but for now it seems like they match the docs.

Base automatically changed from al-vm-constraints to al-constraints October 14, 2025 11:51
@Al-Kindi-0 Al-Kindi-0 added the no changelog This PR does not require an entry in the `CHANGELOG.md` file label Oct 14, 2025
@Al-Kindi-0 Al-Kindi-0 merged commit 16ed6cf into al-constraints Oct 14, 2025
8 of 9 checks passed
@Al-Kindi-0 Al-Kindi-0 deleted the al-hasher-constraints branch October 14, 2025 11:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no changelog This PR does not require an entry in the `CHANGELOG.md` file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants