EIP-6110: Add deposit validation and apis

[ensi321]

PR description

This PR is the continuation of #5055. It is the final PR for EIP-6110. The following are the main features introduced:

• Decode and extract deposit from transaction receipt log
• Introduce depositContractAddress field in genesis file
• Validate deposits in a block against the transaction receipt logs
• Update engine_newPayloadV2 and engine_getPayloadV2 according to the spec. Some of the non-functional components were partially implemented in the previous PR

Fixed Issue(s)

#5004

Testing

• Local block production pre-V6110
• Public testnet sync
• Public mainnet sync

[github-actions]

• I thought about documentation and added the doc-change-required label to this PR if updates are required.
• I have considered running ./gradlew acceptanceTestNonMainnet locally if my PR affects non-mainnet modules.
• I thought about the changelog and included a changelog update if required.

[siladu]

Did a first pass looks pretty straight forward to me. The deposit parsing and validation is simple and easy to understand. Some initial comments, mostly naming.

Next pass I will review against the EIP and execution-api spec in more detail.

[ahamlat]

To accurately gauge the impact of this PR on Besu's performance, particularly regarding block processing, the most effective approach is to deploy it on a dedicated environment with real data. It's preferable to use an environment with many deposits, and then profile the node to observe any impact on performance. In the meantime, I've identified two pertinent methods to assess performance by conducting microbenchmarking with JMH

• DepositDecoder.decodeFromLog
• BodyValidation.depositRoots

During block processing, both methods are invoked, with DepositDecoder.decodeFromLog being called iteratively within a loop that depends on the quantity of receipts and logs per receipt present in the block

Block processing

AbstractEngineNewPayload.syncResponse
        BodyValidation.depositsRoot
	MergeCoodinator.rememberBlock
		MergeCoodinator.validateBlock
			MainnetBlockValidator.validateAndProcessBlock
				MainnetBlockValidator.validateAndProcessBlock
					MainnetBlockBodyValidator.validateBodyLight
						AllowedDeposits.validateDeposits
							DepositDecoder.decodeFromLog (called several times)
						AllowedDeposits.validateDepositsRoot
							BodyValidation.depositsRoot	

Block creation

AbstractBlockCreator.createBlock
	BodyValidation.depositsRoot
	DepositDecoder.decodeFromLog (called several times)

The microbenchmarking of both methods (Keccak256 was added to enable a comparison point)

Benchmark                                     Mode  Cnt       Score      Error  Units
DepositDecoder.decodeFromLogBenchmark         avgt  100   12261.105 ±   80.786  ns/op
DepositDecoder.keccakk256Benchmark            avgt  100     306.937 ±    0.377  ns/op
BodyValidation.depositsRootBenchmark          avgt  100  238915.938 ± 4451.589  ns/op

If I'm not wrong, BodyValidation.depositRoots is called twice during block processing, and it takes 1/4 ms to execute, I think we can save one execution but even with both executions, the overhead is acceptable.

DepositDecoder.decodeFromLog overhead will depends on the number of receipts per block and the number of logs per receipt. If there're for example 1000 logs to process, this represents 13 ms overhead for block processing and block creation.

I started also a node on mainnet with PR to test against main on current fork (previous commit of this PR 795b7c4), I don't see any performance regression on block processing or FCU

From what I gathered, I don't see a blocker to merge this PR in termes of performance

[siladu]

I've started a regression test, fresh X_CHECKPOINT sync of 3 BONSAI nodes: sepolia, goerli, mainnet.

[siladu]

I've started a regression test, fresh X_CHECKPOINT sync of 3 BONSAI nodes: sepolia, goerli, mainnet.

This has passed regression: all nodes got in sync and have stayed in sync. No errors in the logs.

[siladu]

Looking very close now!
Couple of minor things, main one is a potentially missing depositContractAddress filter.

Also can you add a changelog entry please :)

[siladu]

Reran some regression tests (deposits disabled) on latest changes with a local interop and sepolia sync ✅
Think this is ready to merge if @jframe is happy with latest changes.

[jframe]

Reran some regression tests (deposits disabled) on latest changes with a local interop and sepolia sync ✅ Think this is ready to merge if @jframe is happy with latest changes.

Looks fine to me

[siladu]

Thanks @jframe. I will hold off merging until we are sure main branch is clear: there are some issues on main found during the 23.4.2 soak.