Skip to content

Feat/query 1b binary#79

Closed
MonkeyKing-1 wants to merge 147 commits intomainfrom
feat/query-1b-binary
Closed

Feat/query 1b binary#79
MonkeyKing-1 wants to merge 147 commits intomainfrom
feat/query-1b-binary

Conversation

@MonkeyKing-1
Copy link
Copy Markdown
Contributor

Here is the list of commands to run:

cargo run --release --bin afs-1b -- mock write -f bin/afs-1b/tests/data/test_input_file_32_1024.afi -d bin/afs-1b/tests/data/db -o my_table
(This creates a table named my_table, initialized with data from test_input_file_32_1024)

cargo run --release --bin afs-1b -- keygen -o bin/afs-1b/tests/data/keys
cargo run --release --bin afs-1b -- prove -k bin/afs-1b/tests/data/keys -f bin/afs-1b/tests/data/56k_write_32_1024.afi -d bin/afs-1b/tests/data/db -c bin/afs-1b/tests/data/db
cargo run --release --bin afs-1b -- verify -t my_table -d bin/afs-1b/tests/data/db -k bin/afs-1b/tests/data/keys

bfan05 and others added 30 commits May 29, 2024 16:49
@jonathanpwang
Copy link
Copy Markdown
Contributor

@MonkeyKing-1 can you merge main into this after you merge your multi-tier PR? I'll take a look after

@jonathanpwang
Copy link
Copy Markdown
Contributor

Superseded by #198

@jonathanpwang jonathanpwang deleted the feat/query-1b-binary branch July 26, 2024 07:40
jonathanpwang pushed a commit that referenced this pull request Mar 9, 2025
**Finding Link:** Internal finding.

## Description of Fix

Since each block adds 17 rows, the unpadded trace height is always a
multiple of 17 and thus never a power of 2. So there will always be at
least one padding row following the last block.

It was discovered that this assumption is already being used in one
place: when calling `eval_prev_hash`.

The SHA-256 VM extension spec update PR documents this assumption in
code comments. See
axiom-crypto/openvm-private#69

This PR removes a constraint that becomes redundant given the assumption
that there is always at least one padding row following the last block.

More specifically, it cannot be the case that it is the last row of the
trace and it is also a digest row, so the removed constraint is never
enforced.
jonathanpwang pushed a commit that referenced this pull request Mar 9, 2025
**Finding Link:** Internal finding.

## Description of Fix

Since each block adds 17 rows, the unpadded trace height is always a
multiple of 17 and thus never a power of 2. So there will always be at
least one padding row following the last block.

It was discovered that this assumption is already being used in one
place: when calling `eval_prev_hash`.

The SHA-256 VM extension spec update PR documents this assumption in
code comments. See
axiom-crypto/openvm-private#69

This PR removes a constraint that becomes redundant given the assumption
that there is always at least one padding row following the last block.

More specifically, it cannot be the case that it is the last row of the
trace and it is also a digest row, so the removed constraint is never
enforced.
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.

6 participants