Improve End-to-End Test Execution Times for CL+EL Tests

[marioevz]

At the moment, simulators eth2/testnet and eth2/engine perform end-to-end tests which utilize both an Execution Client and a Consensus Client.

Configuration for tests included in these simulators involve a setup of a genesis state, and waiting until enough epochs have passed for the consensus client to reach a certain fork (bellatrix in most cases), which, even with slot times reduced from 12s to 6s, takes too much time to run.

Some clients take up to 15 minutes to complete these tests because of this, and execution times this high results in having unacceptable runtimes for these test suites.

Even when the client supports starting with a certain fork already activated, some tests require reaching a finalization state to be able to verify a certain behavior that only happens after finalization; E.g.:

hive/simulators/eth2/engine/scenarios.go

Lines 137 to 158 in 619a7dd

	// Test `latest`, `safe`, `finalized` block labels on the post-merge testnet.
	func BlockLatestSafeFinalized(t *hivesim.T, env *testEnv, n node) {
	config := getClientConfig(n).join(&Config{
	Nodes: []node{
	n,
	n,
	},
	})
	testnet := startTestnet(t, env, config)
	defer testnet.stopTestnet()
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()
	_, err := testnet.WaitForExecutionFinality(ctx, testnet.spec.SLOTS_PER_EPOCH*beacon.Slot(EPOCHS_TO_FINALITY+2))
	if err != nil {
	t.Fatalf("FAIL: Waiting for execution finality: %v", err)
	}
	if err := VerifyELBlockLabels(testnet, ctx); err != nil {
	t.Fatalf("FAIL: Verifying EL block labels: %v", err)
	}
	}

These excessive runtimes will become more apparent and troublesome when more end-to-end tests are added to future enhancements such as Withdrawals or EIP-4844.

Repository https://github.com/ethereum/consensus-spec-tests contains test vectors which are consumed by the consensus clients, but these tests don't allow (afaik) to test the end-to-end interaction with other beacon clients or with the execution client, which has proven to surface many unexpected errors in the past.

I would like to start the discussion on a list of possible ideas on what an end-to-end testing environment would require from the CLs to become more efficient, but these are not by any means final, and will certainly use some feedback. Perhaps some of these are already implemented (Weak subjectivity perhaps has this functionality?).

• A standard interface that allows to consume, execute and apply a certain state or number of beacon blocks on demand; Perhaps the beacon blocks applied by this interface also result in the appropriate calls to the Engine API
• A standard interface that allows to modify the clock of the beacon client for testing purposes