test(proof): add failing case
Following convo on Signal, I create this draft PR to demonstrate the bug and report all the informations.
Disclaimer
I didn't test all the different scenarios so there might be other cases of proof generation that are incorrect. The case I present here is the one I had a chance to reproduce, but I found an other scenario where the proof was also incorrect but differently than the case here.
Context
While I was asserting the behavior of tm2 proofs (for the IBC connection with A1), and I found an issue with absence proofs.
The test TestTreeGetWithProof() (modified in this PR) builds a merkle tree with keys 0x11, 0x32, 0x50, 0x72, 0x99, and so looks like this:
- Node label is
KEY / HASH - The first two leafs are numbered with 1 and 2 for the purpose of the demo.
After asserting a proof of the presence of the key 0x32, which is not relevant here, the test asserts a proof of the absence of key 0x1. The returned proof is correct and asserts that 0x1 is absent of the tree. In term of leaves, the proof contains only the leaf 1, because 0x1 < 0x11 (key of 1).
Now if that key is changed to 0x1100 like in this PR, the returned proof is exactly the same as with 0x1, but this is incorrect because this time 0x1100 > 0x11. For that proof to be correct, the proof's leaves should contain both 1 and 2 because 0x1100 is between 0x11 and 0x32.
Hence the verification algorithm returns an error, given that absence of second leaf: absence not proved by right leaf (need another leaf?)
🛠 PR Checks Summary
🔴 Pending initial approval by a review team member, or review from tech-staff
Manual Checks (for Reviewers):
- [ ] IGNORE the bot requirements for this PR (force green CI check)
Read More
🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.
✅ Automated Checks (for Contributors):
🟢 Maintainers must be able to edit this pull request (more info) 🔴 Pending initial approval by a review team member, or review from tech-staff
☑️ Contributor Actions:
- Fix any issues flagged by automated checks.
- Follow the Contributor Checklist to ensure your PR is ready for review.
- Add new tests, or document why they are unnecessary.
- Provide clear examples/screenshots, if necessary.
- Update documentation, if required.
- Ensure no breaking changes, or include
BREAKING CHANGEnotes. - Link related issues/PRs, where applicable.
☑️ Reviewer Actions:
- Complete manual checks for the PR, including the guidelines and additional checks if applicable.
📚 Resources:
Debug
Automated Checks
Maintainers must be able to edit this pull request (more info)
If
🟢 Condition met └── 🟢 And ├── 🟢 The base branch matches this pattern: ^master$ └── 🟢 The pull request was created from a fork (head branch repo: tbruyelle/gno)Then
🟢 Requirement satisfied └── 🟢 Maintainer can modify this pull requestPending initial approval by a review team member, or review from tech-staff
If
🟢 Condition met └── 🟢 And ├── 🟢 The base branch matches this pattern: ^master$ └── 🟢 Not (🔴 Pull request author is a member of the team: tech-staff)Then
🔴 Requirement not satisfied └── 🔴 If ├── 🟢 Condition │ └── 🟢 Or │ ├── 🔴 At least 1 user(s) of the organization reviewed the pull request (with state "APPROVED") │ ├── 🔴 At least 1 user(s) of the team tech-staff reviewed pull request │ └── 🟢 This pull request is a draft └── 🔴 Then └── 🔴 And ├── 🟢 Not (🔴 This label is applied to pull request: review/triage-pending) └── 🔴 At least 1 user(s) of the team tech-staff reviewed pull requestManual Checks
**IGNORE** the bot requirements for this PR (force green CI check)
If
🟢 Condition met └── 🟢 On every pull requestCan be checked by
- Any user with comment edit permission
Fixed by #4656