Skip to content

feat: Change proof serialization/deserialization#1638

Merged
bernard-avalabs merged 27 commits intomainfrom
bernard/change-proof-api-v3-part2
Feb 13, 2026
Merged

feat: Change proof serialization/deserialization#1638
bernard-avalabs merged 27 commits intomainfrom
bernard/change-proof-api-v3-part2

Conversation

@bernard-avalabs
Copy link
Contributor

@bernard-avalabs bernard-avalabs commented Jan 25, 2026

Why this should be merged

Second PR for change proof FFI (builds on #1637). This PR includes fwd_change_proof_to_bytes and fwd_change_proof_from_bytes for serialization/deserization of a change proof.

How this works

Mostly follows the serialization/deserialization implementation in range proof. Main change is to support serializing/deserializing BatchOps which are used for storing the difference between two revisions.

How this was tested

Basic serialization and deserialization tests in proofs_test.go, including a round trip test where a change proof is serialized, deserialized, and serialized again, and verifying the two serialized proofs match.

r.NoError(err)
}

func TestChangeProofDiffersAfterUpdate(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

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

It's not totally clear what this is testing. Wouldn't being able to commit a change proof and resulting in the correct root mean that they contain the correct data? It seems that this might just be an intermediate test until that functionality is present, but if that's the case, will you add a //TODO: delete this once verification and commitment are implemented. If you think this test will continue to be necessary after that, can you argue why?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test is based on TestRangeProofDiffersAfterUpdate. Similar to TestChangeProofEmptyDB, its mainly to check basic functionality, namely the ability to create a serialized change proof from two non-empty revisions without error, and to verify that serialized versions of distinct change proofs are different.

It can catch serialization issues that simply checking the root hash will miss. However, TestRoundTripChangeProofSerialization is a more comprehensive test for serialization/deserialization.

It don't think it hurts to keep it since it is a short test. But I can remove it if you don't think it is necessary.

Comment on lines +111 to +113
found => Err(ReadError::InvalidHeader(
InvalidHeader::UnsupportedVersion { found },
)),
Copy link
Member

Choose a reason for hiding this comment

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

nit: would have preferred this error is handled before the main code instead of indenting. Also a shame bool::ok_or is not stable yet. Maybe:

if header.version != 0 {
    return Err(ReadError::InvalidHeader(
                InvalidHeader::UnsupportedVersion { found },
            ))
}
let mut reader = ...

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've made this change.

Base automatically changed from bernard/change-proof-api-v3 to main January 27, 2026 20:15
.read_item::<u8>()
.map_err(|err| err.set_item("option discriminant"))?
{
0 => Ok(BatchOp::Put {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: you can use the constants here in the match pattern as well.

@bernard-avalabs bernard-avalabs merged commit 38c9956 into main Feb 13, 2026
51 checks passed
@bernard-avalabs bernard-avalabs deleted the bernard/change-proof-api-v3-part2 branch February 13, 2026 03:12
bernard-avalabs added a commit that referenced this pull request Feb 24, 2026
## Why this should be merged

Builds on #1638. Verifies a
change proof and creates a proposal on the destination trie.

## How this works

Mostly follows the implementation from range proofs with some additional
checks that are specific to change proofs. The interface for range
proofs has a separate function for verify (`fwd_range_proof_verify`) and
verify and propose (`fwd_db_verify_range_proof`). The change proof
interface only has verify, but the comments explains that it also
prepares a proposal. I have follow the comment by implementing proof
verification and proposal creation in the verify function.

## How this was tested

A basic test was added in `proofs_test.go` that creates a change proof
and verifies it and check that it does not return an error. More
end-to-end tests will be added in a later PR.
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.

4 participants