Support SSZ Engine

[syjn99]

🦄 Feature Tracking

Current status

Opt-in feature flag name: --engine-ssz-http

Feature Description

Implements ethereum/execution-apis#793. (Spec is still subject to change)

#16901 implements most of the functionality for the spec commit ethereum/execution-apis@e509f20.

This issue will track to land the full work of #16901 step by step:

• Extract JSON-RPC engine code into its own files. More simply, debloat engine_client.go with full of JSON-RPC related code. (SSZ Engine: Extract JSON-RPC engine code into separate files #17047)
• Add an interface ExecutionPayloadBody: (SSZ Engine: Add abstraction layer on Engine call in Execution service #17135)

// ExecutionPayloadBody represents the execution payload body from Engine API.
type ExecutionPayloadBody interface {
	IsNil() bool
	Transactions() ([][]byte, error)
	Withdrawals() ([]*enginev1.Withdrawal, error)
	BlockAccessList() ([]byte, error)
}

• Add an abstraction layer for Engine client. Ideally, this interface should be implemented for SSZ Engine and JSON-RPC Engine: (SSZ Engine: Add abstraction layer on Engine call in Execution service #17135)

type engineTransport interface {
	NewPayload(...) ([]byte, error)
	ForkchoiceUpdated(...) (*pb.PayloadIDBytes, []byte, error)
	GetPayload(...) (*blocks.GetPayloadResponse, error)
	GetBlobs(...) ([]*pb.BlobAndProof, error)
	GetBlobsV2(...) ([]*pb.BlobAndProofV2, error)
	ExchangeCapabilities(ctx context.Context) error
	GetClientVersionV1(ctx context.Context) ([]*structs.ClientVersionV1, error)
	GetPayloadBodiesByHash(...) ([]interfaces.ExecutionPayloadBody, error)
	GetPayloadBodiesByRange(...) ([]interfaces.ExecutionPayloadBody, error)
}

Note

The Execution Service will have engine() method that routes the call to available transport: SSZ-HTTP or JSON-RPC.

• Generate proto files for new data structures.
• Implement SSZ-HTTP Engine callers and wire with the abstraction layer. This phase will include --engine-ssz-http flag.
• Engine transport metrics

Tasks

• Feature flag created as opt-in
• Feature implemented / code complete
• Feature tested in production for adequate amount of time
• Feature flag is inverted to be opt-out and the opt-in flag is deprecated
• Feature has made it to a tagged production release as an opt-out flag
• Opt-out feature flag is deprecated and old code paths are cleaned up

This issue should be closed after all of the above tasks are complete.