feat: run the l1 info tree syncer with safe block finality

[Stefan-Ethernal]

🔄 Changes Summary

• Change the L1 Info Tree Syncer block finality to safe, in order to make aggoracle runs faster. Re-introduce BlockFinality in the L1InfoTreeSyncer config and consequently the ReorgDetector.
• Simplify keccak256 hash calculations, by relying on go ethereum library.
• Remove URLRPCL1 config parameters from Aggoracle and L1InfoTreeSync, since they are unused.
• Introduce abstractions for merkle trees, in order to test l1 info tree syncer processor more deeply:
  • ReadTreer – provides read-only access to tree data (roots, leaves, proofs).
  • LeafWriter – defines write operations for adding new leaves to the tree.
  • ReorganizeTreer – extends ReadTreer with the ability to handle blockchain reorgs.
  • FullTreer – combines all capabilities (ReadTreer, LeafWriter, ReorganizeTreer), representing a fully functional, mutable Merkle tree.

⚠️ Breaking Changes

N/A

📋 Config Updates

• Re-introduce L1InfoTreeSync.BlockFinality config param.
• Remove Aggoracle.URLRPCL1 config param.
• Remove L1InfoTreeSync.URLRPCL1 config param.

✅ Testing

• 🤖 Automatic: [Optional: Enumerate E2E tests]
• 🖱️ Manual: [Optional: Steps to verify]

🐞 Issues

• Closes Aggoracle should process GERs at a faster pace #1170

🔗 Related PRs

N/A

📝 Notes

N/A

[Copilot]

Pull Request Overview

This PR refactors hash computation to use the standard crypto.Keccak256Hash function instead of manual sha3 implementations, removes an unused field from EVMDownloader, changes pointer receivers to value receivers where appropriate, and adds a new GetLatestL1InfoGER method to directly retrieve the Global Exit Root without fetching the entire leaf object.

• Replaces manual sha3.NewLegacyKeccak256() implementations with crypto.Keccak256Hash calls
• Removes unused finalizedBlockType field from EVMDownloader struct
• Adds GetLatestL1InfoGER method to efficiently retrieve only the GER without the full leaf

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
types/block_finality.go	Changed BlockNumber method receiver from pointer to value
tree/tree.go	Replaced manual sha3 hashing with crypto.Keccak256Hash, removed sha3 import
sync/evmdownloader.go	Removed unused finalizedBlockType field from struct
l1infotreesync/processor.go	Replaced manual sha3 hashing with crypto.Keccak256Hash in CalculateGER, added GetLatestL1InfoGER method
l1infotreesync/processor_test.go	Added tests for new GetLatestL1InfoGER functionality and CalculateGER, removed unnecessary loop variable shadowing
l1infotreesync/l1infotreesync.go	Added GetLatestL1InfoGER public method, fixed grammar in comment
l1infotreesync/l1infotreesync_test.go	Added test for GetLatestL1InfoGER error handling
l1infotreesync/e2e_test.go	Updated loop syntax to range expression, added GetLatestL1InfoGER verification
go.mod	Moved golang.org/x/crypto from direct to indirect dependency
cmd/run.go	Renamed parameters for clarity, changed finality type from FinalizedBlock to SafeBlock, changed type to interface
aggoracle/oracle.go	Updated L1InfoTreeSyncer interface to use GetLatestL1InfoGER instead of GetLatestL1InfoLeaf
aggoracle/e2e_test.go	Updated loop syntax to range expression

[joanestebanr]

The coverage is below 80%

[joanestebanr]

are we sure that we want Safe as default? the situation of changing to Safe is for always or just an specific use case?

[Stefan-Ethernal]

The original requirement was to make the safe, in order to make the aggoracle runs faster (and consequentially be able to inject GERs at a higher frequency). Also I understand this is just an intermediary approach until syncers and reorg detector is refactored. Note that, in the near future, we are aiming to have GERs injected on every 6th L1 block, which is considered as good enough (and thus probably unlikely to be reorged). As you can see on the Etherscan, the reorgs are happening, but are often pretty shallow (most often the fork is only 1 block deep)

As it is highly unlikely that the safe block gets reorged, I think it makes sense to run on this BlockFinality by default. If for any reason we experience some issues, we can always override it through a config.

IMO it would be an overkill at this point to refactor this, and create a separate configuration for the aggoracle on the Kurtosis CDK and what not.

cc @arnaubennassar

[vcastellm]

I'm in for setting this as Default, the "highly unlikely" in the safe definition is quite high.

No, safe blocks have not been reorged in Ethereum. A "safe" block is one that has received attestations from two-thirds of the validator set, making it highly unlikely to be reorganized under normal network conditions. Reorganizations of "safe" blocks would require a catastrophic attack on the network, as it is understood to be crypto-economically secure.

[vcastellm]

LGTM

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
81.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud