Build block with empty transactions if prepare_payload fails

[dapplion]

If the execution client is not able to prepare or deliver a block the consensus client could create a valid execution payload on its own with no transactions. Before skipping the slot, this would allow consensus operations to be included on-chain, a lesser of two evils

[mkalinin]

Is this the case when the payload of the parent block has been verified but for some reason EL failed to produce a block on demand?

Otherwise, if EL is down and the parent payload hasn't been verified then it means that the parent beacon block can't be deemed valid and there is a risk of producing on top of an invalid block with all the implications. Validator MUST NOT perform any of its duties (either proposing or attesting) until execution is verified.

[dapplion]

Is this the case when the payload of the parent block has been verified but for some reason EL failed to produce a block on demand?

Otherwise, if EL is down and the parent payload hasn't been verified then it means that the parent beacon block can't be deemed valid and there is a risk of producing on top of an invalid block with all the implications. Validator MUST NOT perform any of its duties (either proposing or attesting) until execution is verified.

Yes, the parent has been validated by execution layer, but execution engine is not available to produce the next block. Other consensus clients could validate this block without execution layer provided it has 0 transactions.

[mkalinin]

Yes, the parent has been validated by execution layer, but execution engine is not available to produce the next block. Other consensus clients could validate this block without execution layer provided it has 0 transactions.

Producing empty payload is the potential fallback behaviour for CL client in this case. This case is not that frequent, though. The question is would CL want to support RLP and keccak256 to handle it, should be up to implementation

[dapplion]

Yes, the parent has been validated by execution layer, but execution engine is not available to produce the next block. Other consensus clients could validate this block without execution layer provided it has 0 transactions.

Producing empty payload is the potential fallback behaviour for CL client in this case. This case is not that frequent, though. The question is would CL want to support RLP and keccak256 to handle it, should be up to implementation

It could help in a network wide outage where Geth experiments a critical failure, it won't stall consensus too, only EL.

[mkalinin]

Yes, the parent has been validated by execution layer, but execution engine is not available to produce the next block. Other consensus clients could validate this block without execution layer provided it has 0 transactions.

Producing empty payload is the potential fallback behaviour for CL client in this case. This case is not that frequent, though. The question is would CL want to support RLP and keccak256 to handle it, should be up to implementation

It could help in a network wide outage where Geth experiments a critical failure, it won't stall consensus too, only EL.

Oh, I see what you mean. It will stop working when a proposer that having another EL client proposes a payload with non-empty transaction list. Until that point it could definitely be helpful and contribute to the network liveness. Though, we're targeting client diversity and ideally a number of consecutive EL failures should approach zero.

[dapplion]

Oh, I see what you mean. It will stop working when a proposer that having another EL client proposes a payload with non-empty transaction list. Until that point it could definitely be helpful and contribute to the network liveness. Though, we're targeting client diversity and ideally a number of consecutive EL failures should approach zero.

Even if one single EL client fails you are trading a skipped slot against a slot with consensus data and no execution data

[mkalinin]

Oh, I see what you mean. It will stop working when a proposer that having another EL client proposes a payload with non-empty transaction list. Until that point it could definitely be helpful and contribute to the network liveness. Though, we're targeting client diversity and ideally a number of consecutive EL failures should approach zero.

Even if one single EL client fails you are trading a skipped slot against a slot with consensus data and no execution data

Right and it should be possible to be implemented on CL side without an update to the spec

[dapplion]

Right and it should be possible to be implemented on CL side without an update to the spec

While it does not affect the spec it can significantly alter network behavior. Would a note or recommendation by appropriate?

[mkalinin]

Right and it should be possible to be implemented on CL side without an update to the spec

While it does not affect the spec it can significantly alter network behavior. Would a note or recommendation by appropriate?

I would say this is potentially dangerous because one may decide that they can propose on not yet validated block after seeing anything like that in the spec. Or it can be handled with yet another Note under the first one, hmmm. Could be as follows:

Note: Client software MUST NOT propose on or attest to a block which isn't deemed valid, i.e. passed the beacon chain state transition function and execution verifications.
Note: Client software MAY propose a block with a payload having empty transactions list in case if ExecutionEngine.get_payload failed to respond with a payload.

[dapplion]

Note: Client software MUST NOT propose on or attest to a block which isn't deemed valid, i.e. passed the beacon chain state transition function and execution verifications.
Note: Client software MAY propose a block with a payload having empty transactions list in case if ExecutionEngine.get_payload failed to respond with a payload.

Those both notes look good to me. The first one is already relevant in the context of a post-merge sync.

[djrtwo]

I'm not sure we should put this in the spec. While it is an optional correct behavior, it represents some failure in your local node and puts a requirement to be able to perform keccak hashes of the executionPayload on CL side.

If we do put it in the spec, we'll have to define what a "correct" empty payload looks like and how to hash it properly. In terms of keeping the layers separated on a spec level, it would be much cleaner to leave it as is. And if a CL client wants to optimize for this case, and produce a valid block of empty txs, they can.

I mainly don't want to be in the habit of spec-ing the same behavior (or subset of behavior) in both CL and EL which this would require. (Same reason that I'm loosely in favor of removing gas validations on CL spec)

While it does not affect the spec it can significantly alter network behavior

Does it significantly alter network behavior? If we abstract an EL into one that can either give us a valid payload full of TXs or a fallback payload with no TXs, then whether in practice EL or CL does it, both look like correct behavior and we might see it anyway.

[mkalinin]

The first note that has been discussed in this issue has been added to the spec #2703. I am closing the issue as everyone seems to be agree on leaving the opportunity of building empty payload as a fallback out of specification.