feat(besu): add IBFT 2.0 and QBFT light clients

[gjermundgaraba]

Description

closes: #XXXX

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
• Wrote unit and integration tests.
• Added relevant natspec and godoc comments.
• Provide a conventional commit message to follow the repository standards.
• Re-reviewed Files changed in the GitHub PR explorer.
• Review SonarCloud Report in the comment section below once CI passes.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[greptile-apps]

Greptile Summary

The PR adds Solidity light clients and proof-service support for Besu IBFT 2.0 and QBFT networks, together with generated bindings, fixtures, and end-to-end infrastructure.

• Adds Besu header, validator quorum, account-proof, and storage-proof verification.
• Registers Besu-to-Besu and dummy-EVM proof API modules.
• Adds single- and dual-Besu test environments covering deployment, client registration, packet receipt, and acknowledgement relay.
• Expands generated ABI validation and documents supported Besu configurations.

Confidence Score: 5/5

The PR appears safe to merge because no blocking failure remains within the eligible follow-up review scope.

No blocking failure remains.

Important Files Changed

Filename	Overview
ibc-solidity/contracts/light-clients/besu/BesuLightClientBase.sol	Implements shared Besu header parsing, validator quorum checks, trusted-state updates, and EVM account and storage proof verification.
ibc-solidity/contracts/light-clients/besu/BesuIBFT2LightClient.sol	Specializes the shared client for IBFT 2.0 commit-seal digest construction.
ibc-solidity/contracts/light-clients/besu/BesuQBFTLightClient.sol	Specializes the shared client for QBFT commit-seal digest construction.
packages/proof-api/modules/besu-to-besu/src/tx_builder.rs	Constructs Besu client creation, update, packet relay, and proof-bearing destination transactions.
packages/proof-api/modules/besu-to-besu/src/lib.rs	Exposes the Besu-to-Besu proof API route and dispatches shared service operations.
e2e/interchaintestv8/chainconfig/besu_qbft.go	Creates and manages a four-validator Docker Compose QBFT network for end-to-end tests.
e2e/interchaintestv8/besu_to_besu_test.go	Exercises dual-Besu deployment, client registration, token transfer, packet receipt, and acknowledgement relay.
programs/proof-api/src/bin/proof-api.rs	Registers the new Besu-to-Besu and dummy-EVM proof API modules with the server.

Sequence Diagram

sequenceDiagram
  participant A as Besu Chain A
  participant P as Proof API
  participant B as Besu Chain B
  participant LC as Besu Light Client
  A->>A: Send packet and store commitment
  P->>A: Read header, event, and storage proof
  P-->>B: Build update and receive transaction
  B->>LC: Verify header, validator quorum, and account root
  LC-->>B: Verify packet commitment proof
  B->>B: Receive packet and write acknowledgement
  P->>B: Read acknowledgement proof
  P-->>A: Build acknowledgement relay
  A->>LC: Verify updated B state and acknowledgement
  A->>A: Complete packet lifecycle

Loading

_{Reviews (2): Last reviewed commit: "fix(besu): decouple relay safety API" | Re-trigger Greptile}

[gjermundgaraba]

@greptile review

[srdtrk]

First pass. I'm still reviewing the proof api code

[srdtrk]

This is cool. It does feel a bit weird that we have to hard code IPs, number of validators, and the images used. Maybe this file should be generated from a template?

[gjermundgaraba]

we can consider it, for now i left it since besu requires deterministic addresses

[srdtrk]

smarter thing to do is to get this by parsing the timeout events, getting the timestamp and then converting it to a height. However, I understand that it might be cumbersome. If we can modify proof API to use timestamps for timeouts rather than block heights, that might be more ideal.

[gjermundgaraba]

yeah, might be worth considering, but in the proof api as it is, i dont think it is worth doing rn (perhaps in ibc "link")

[srdtrk]

I wonder if we can query the chains to figure this out to remove the need for this config param. Would improve the UX a lot imo.

[gjermundgaraba]

would. we should look into it when we move this over to link

[srdtrk]

lgtm