eth/executionclient: order packed logs by logIndex within a transaction

[iurii-ssv]

Summary

PackLogs sorted logs by (block, txIndex) using a non-stable sort.Slice, so logs emitted by the same transaction (same txIndex) were left in unspecified relative order.

A single transaction can emit multiple order-dependent registry events: bulkRegisterValidator emits one ValidatorAdded per validator, each bumping the owner's per-owner nonce. If those get packed out of logIndex order, the event handler's GetNextNonce/BumpNonce sequence no longer matches the events' signed nonces → verifySignature fails → MalformedEventError (and the nonce is still bumped), silently rejecting otherwise-valid registrations.

It's usually masked in practice — Go's sort.Slice is stable for small slices — but it's unsound and can surface with a larger batch or a runtime change.

Fix

Add a logIndex (Index) tiebreaker so PackLogs sorts by (block, txIndex, logIndex) — logIndex is unique and monotonic within a block, so packing now preserves canonical on-chain order both across and within a transaction. Existing (block, txIndex) behavior is unchanged for logs in distinct transactions.

Regression test added with shuffled same-transaction logs.

Noticed during review of #2991.

[greptile-apps]

Greptile Summary

This PR makes execution-log packing preserve canonical on-chain order within each transaction and adds regression coverage for shuffled same-transaction logs.

• Sorts logs by block number, transaction index, and log index.
• Verifies that same-transaction logs are packed in ascending log-index order.

Confidence Score: 5/5

The PR appears safe to merge, with the new comparator consistently preserving canonical event order across historical and streaming fetch paths.

The production fetch paths populate block, transaction, and log indices before calling PackLogs, and the grouping logic preserves the resulting order; no blocking or independently actionable issue remains.

Important Files Changed

Filename	Overview
eth/executionclient/logs.go	Adds the log-index tiebreaker needed to preserve canonical ordering before block-level event processing.
eth/executionclient/logs_test.go	Adds focused regression coverage for shuffled logs from the same transaction.

_{Reviews (1): Last reviewed commit: "eth/executionclient: order packed logs b..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.2%. Comparing base (48d4f3a) to head (de7575b).

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ovidiu-ssv-labs]

Correct, minimal, well-targeted fix: adding the logIndex tiebreaker makes PackLogs produce true canonical on-chain order, which the nonce-sequenced ValidatorAdded handler depends on. Verified the new regression test actually fails against the pre-PR comparator, and that the bug was deterministic (not just theoretical) for same-tx batches above ~12 logs. One minor follow-up: a second copy of the old comparator still lives in bloom.go. [verdict: yes]

Finding 1 · [MINOR] Deduplicate the log comparator — bloom.go still sorts by (block, txIndex) only — eth/executionclient/bloom.go:86

verifyLogsWithBloom re-sorts after appending bloom-recovered logs using a comparator that is the exact pre-PR version this PR just fixed — (block, txIndex) only, no logIndex tiebreak. No impact today: verifyLogsWithBloom has exactly one caller, and its output flows straight into PackLogs, which now re-sorts with the full corrected comparator — so the weaker sort here is currently harmless and redundant.

It still matters because the codebase now has two comparators over the same data that disagree, and the weaker one sits directly in the path that appends recovered logs — precisely the operation that destroys incoming order. If verifyLogsWithBloom is ever reused outside the PackLogs path, or these two steps are reordered, the exact nonce-mismatch failure this PR fixes silently returns — and would only trigger on the rare bloom-recovery path, making it extremely hard to reproduce. For scale: the pre-PR comparator, run over 40 same-tx logs in reverse order, returned them still fully reversed — above ~12 elements Go's sort.Slice is not merely unspecified, it's deterministically wrong.

[ovidiu-ssv-labs]

1 minor comment only, see above.