Merged
Conversation
benesjan
changed the title
benesjan
added
ci-no-fail-fast
benesjan
force-pushed
the
01-23-feat_typing_blockheader_hash
branch
from
badf7c0 to
a605791
Compare
benesjan
commented
Jan 26, 2026
| return this.header.hash(); | ||
| public async hash(): Promise<Fr> { | ||
| const blockHash = await this.header.hash(); | ||
| return blockHash.toField(); |
Contributor
Author
There was a problem hiding this comment.
I would tackle this in a followup PR.
spalladino
approved these changes
Jan 26, 2026
Contributor
spalladino
left a comment
spalladino
left a comment
There was a problem hiding this comment.
Looks good, but seems like there are a few APIs that still need changing, just by looking at the toField calls.
Also, unrelated to this PR: shouldn't L2BlockHash extend from Fr instead of Buffer32, given it's a field element? And also, we should probably add some branding to the L2BlockHash to avoid mixing it up with vanilla Frs. But neither of this are specific for this PR.
Contributor
Author
|
Good points. Will adress in a follow-up PR. @spalladino Thanks for the review! |
AztecBot
force-pushed
the
01-23-feat_typing_blockheader_hash
branch
from
a605791 to
3a18b49
Compare
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Contributor
Author
|
The |
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Contributor
|
@benesjan heads up that full-prover runs with REAL_PROOFS enabled only on merge queue |
benesjan
force-pushed
the
01-23-feat_typing_blockheader_hash
branch
from
3a18b49 to
94487e8
Compare
When touching Aztec Node endpoints a while ago I had to use there `L2BlockHash` type in order to be able to accept a generic block arg on the input that could represent either a block number or block hash (when I used `Fr` for the block hash there were serialization issues as these 2 types were getting mixed up). But after this I had quite a few ugly conversions in `PXE` between `L2BlockHash` and `Fr`. In this PR I drop some of those conversions. This results in ugly conversions being in some other places but eventually we should use the type everywhere so this is a step in a good direction. Admittedly a low-priority issue but such tech debt even a cheap model like Sonnet is able to tackle so no reason to keep it around.
AztecBot
force-pushed
the
01-23-feat_typing_blockheader_hash
branch
from
94487e8 to
7f0c678
Compare
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Jan 27, 2026
We had an `L2BlockHash` defined in `block_hash.ts` and it was returned from the `hash` function of `BlockHeader`. I didn't like the inconsistency so I decided to just drop "L2" from the class name. Yesterday I merged a [PR](#19899) that touched a lot of this so this might be quite a convenient time to do this (conflicts-wise). I just globally replaced the "L2BlockHash" string with "BlockHash" so checking this in-depth is not really needed.
AztecBot
pushed a commit
that referenced
this pull request
Jan 29, 2026
As Santiago proposed [here](#19899 (review)) makes sense to have `BlockHash` extend from `Fr` instead from `Buffer32` because the hash is the output of Poseidon2 hash and hence natively a field. Also introduced branding to avoid collisions with `Fr` and cleaned up the type from unused functions.
AztecBot
pushed a commit
that referenced
this pull request
Jan 29, 2026
As Santiago proposed [here](#19899 (review)) makes sense to have `BlockHash` extend from `Fr` instead from `Buffer32` because the hash is the output of Poseidon2 hash and hence natively a field. Also introduced branding to avoid collisions with `Fr` and cleaned up the type from unused functions.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Jan 29, 2026
As Santiago proposed [here](#19899 (review)) makes sense to have `BlockHash` extend from `Fr` instead from `Buffer32` because the hash is the output of Poseidon2 hash and hence natively a field. Also introduced branding to avoid collisions with `Fr` and cleaned up the type from unused functions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When touching Aztec Node endpoints a while ago I had to use there
L2BlockHashtype in order to be able to accept a generic block arg on the input that could represent either a block number or block hash (when I usedFrfor the block hash there were serialization issues as these 2 types were getting mixed up).But after this I had quite a few ugly conversions in
PXEbetweenL2BlockHashandFr. In this PR I drop some of those conversions.This results in ugly conversions being in some other places but eventually we should use the type everywhere so this is a step in a good direction.
Admittedly a low-priority issue but such tech debt even a cheap model like Sonnet is able to tackle so no reason to keep it around.