[gjermundgaraba]

Description

Stacked on #1581. An end-to-end test of #1581 against real Besu: the relayer steps a Besu light client across validator set changes made by header voting.

• Harness (e2e/internal/harness/chain/evm/besu/besu.go): a managed Besu chain can run several nodes (ManagedBesu.Nodes). The first validates from genesis; the others follow it, peered over the Docker bridge through a static-nodes file. A new Chain.Validators() capability votes validators in and out through the QBFT or IBFT 2.0 voting RPCs (qbft_* / ibft_*), waits until the head's set reflects the vote and discards it. It refuses to vote in an address that runs no node of the chain, which would halt it.
• Tests (e2e/transfer_test.go): TestTransferBesuQBFT_ValidatorTurnover and TestTransferBesuIBFT2_ValidatorTurnover run chain B on two nodes and, before any packet is relayed, vote the second node in and the first out. No header at B's head is then sealed by the validator chain A's client trusts, so the transfer from B only relays if the relayer steps the client across both changes.
• Matrix and README: the matrix labels a multi-node chain "Besu QBFT (2 nodes)"; the e2e README describes the tests.

closes: FOU-1612 (Linear, with #1581)

Verification

• Both turnover tests pass in complete mode against Besu 26.5.0 (QBFT 158s, IBFT 2.0 151s), along with every other Besu e2e test on the changed harness.
• Against a CLI built without feat(besu): follow validator set changes the client cannot skip #1581, the QBFT turnover test fails: every relay attempt reverts with InsufficientTrustedValidatorOverlap(0, 1) at gas estimation.
• A two-node spike confirmed that a Besu header lists the validators that sealed it, with a vote taking effect from the next block, as the light client assumes.
• make -C e2e test-harness, make -C e2e lint and make -C e2e generate-matrix are clean.

Not covered end to end: a validator-list override in genesis transitions. Its block must be fixed before the chain starts while the client must be deployed before it, which makes the test timing-fragile; the prover's unit tests cover that case.

---

• Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work. (Linear FOU-1612)
• Include changelog entry when appropriate (e.g. chores should be omitted from changelog). (n/a: CHANGELOG.md only tracks the spec)
• Wrote unit and e2e tests if relevant.
• Updated documentation (docs/) if anything is changed. (e2e/README.md)
• Added godoc comments if relevant.
• Self-reviewed Files changed in the GitHub PR explorer.
• Provide a conventional commit message to follow the repository standards.

🤖 Generated with Claude Code

[linear-code]

FOU-1612

[github-actions]

Vulnerable dependencies

2 advisories across 2 libraries need attention, 2 accepted.

🚨 Needs attention

github.com/cosmos/evm

In use: v0.7.3 — reached from e2e

Advisory	CVE	Fixed in	Summary
GO-2025-3684	—	no fix yet	Cosmos EVM Allows Partial Precompile State Writes in github.com/cosmos/evm

Go standard library

In use: go1.26.9 — reached from cli, e2e, gen/go/solidity-abi

Advisory	CVE	Fixed in	Summary
GO-2026-6809	CVE-2026-111943	go1.26.10	Distrust compromised intermediate certificates in crypto/x509

Run make vulncheck for the call paths. Either upgrade the library, or add the
advisory to .govulncheck-ignore with a reason if no fix exists yet.

Accepted

Listed in .govulncheck-ignore with a reason.

github.com/pion/dtls/v2

In use: v2.2.12 — reached from cli

Advisory	CVE	Fixed in	Summary
GO-2026-4479	CVE-2026-26014	no fix yet	Usage of random nonce generation with AES GCM ciphers risks leaking the authentication key in github.com/pion/dtls

golang.org/x/crypto

In use: v0.57.0 — reached from cli, e2e

Advisory	CVE	Fixed in	Summary
GO-2026-5932	—	no fix yet	The golang.org/x/crypto/openpgp package is unmaintained, unsafe by design, and has known security issues

_{From make vulncheck-json on this run: logs.}

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge; no actionable issues remain.

Summary

Adds QBFT and IBFT 2.0 transfer tests that replace chain B’s original validator before relaying.

• Managed Besu chains can run followers and vote in validators.
• Besu transfer tests relay after the source chain replaces its validator.

No new actionable issues were found. Tests were not run during this review.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A["Deploy clients trusting original validator"] --> B["Vote follower in"]
  B --> C["Vote original validator out"]
  C --> D["Start relayer and send transfer"]
  D --> E["Step client across validator changes"]
  E --> F["Check delivery and acknowledgement"]

Loading

_{Reviews (2) · Last reviewed commit: "fix(e2e): discard Besu validator votes w..." · Reviewed by Greptile}

[gjermundgaraba]

@greptile review

[dhfang]

We should probably not use default of 2/3rds if the light client gets stuck and cannot recover on a validator change.

Let's discuss this thread tomorrow #1581 (comment). I'm wondering if we decided to add the mitigation at the contract level or if right now the recommendation is just to migrate clients if an operator's besu LC gets stuck