C-Fork

[GalRogozinski]

Description

Scope for the fork.

SFI

Increase Correctness

• Leader has incorrect head #83

Helps with proposals (APR Effect: low, maybe will help a few validators ~0.05% of total improvement)

• If not QBFT leader, do not wait for start value
  Prerequisites:
  • Dynamic QBFT Timeout #37
  • Round change according to duty start time ssv-spec#352

Increase chance of duty being included

• Reduce Round Change timeout #82

CFI

Decrease Latency (APR Effect: low-med? Dependent on timing games)

• Do Proposal's pre-consensus as soon as possible in the start of the epoch ssv-spec#373
• Remove Decided Messages from QBFT Consensus #63 (performance)
• Optimize Msg Structures #58 - probably lots of work
• Audit Suggestion 5: Unnecessary checks increase complexity ssv-spec#355
• Move consensus from blinded blocks to beacon block headers (Phase 2) ssv#2544 (see comment)

Previous/Other Discussions (APR Effect: none)

• Handshake Improvements ssv-spec#532
• Incorporate a scheme to replace RSA or fix PEM format #59
• Interactive Consistency For Agg Committee #79
• Finality based event syncing  #67

[nkryuchkov]

Can we add ssvlabs/ssv#2544?
cc @y0sher @olegshmuelov

[GalRogozinski]

We need to see if there are any implications with validations we may have to do for leaderless consensus.

[GalRogozinski]

So pretty much in leaderless consensus all nodes may offer a proposal and we can pick the best one based on:

1. Head Vote
2. Execution Fees

However the proposer may be malicious.
We need to understand what validations we may need to do to detect a malicious proposal and whether ssvlabs/ssv#2544 affects this.

We need to assess whether under current conditions, and after ePBS is activated, there is a difference in the validation we need to make.

[GalRogozinski]

To be clear, I think the CL block header masks EL details that may be needed for validations