Make Electra execution request fields optional for beacon client compatibility #237
Description
Make Electra execution request fields optional for beacon client compatibility
Problem Statement
The current implementation strictly validates all Electra execution request fields (deposit_requests, withdrawal_requests, consolidation_requests), requiring them to be present and non-nil. However, some beacon chain clients omit these fields entirely when they contain no data, causing parsing failures.
This issue is also documented in: sigp/lighthouse#7520
Current Implementation
if data.DepositRequests == nil {
return errors.New("payload attributes deposit requests missing")
}
for i := range data.DepositRequests {
if data.DepositRequests[i] == nil {
return fmt.Errorf("deposit requests entry %d missing", i)
}
}
p.DepositRequests = data.DepositRequests
if data.WithdrawalRequests == nil {
return errors.New("payload attributes withdraw requests missing")
}
for i := range data.WithdrawalRequests {
if data.WithdrawalRequests[i] == nil {
return fmt.Errorf("withdraw requests entry %d missing", i)
}
}
p.WithdrawalRequests = data.WithdrawalRequests
if data.ConsolidationRequests == nil {
return errors.New("payload attributes consolidation requests missing")
}
for i := range data.ConsolidationRequests {
if data.ConsolidationRequests[i] == nil {
return fmt.Errorf("consolidation requests entry %d missing", i)
}
}
p.ConsolidationRequests = data.ConsolidationRequestsRationale
Client Implementation Differences:
- Lighthouse: Omits execution request fields when they contain no data
- Other clients: May include empty arrays
[]for consistency - Specification: Defines fields as lists that can be empty, but doesn't mandate JSON representation when empty
Why This Approach:
- Maintains Data Integrity: Still validates individual entries when present
- Improves Compatibility: Works with all known beacon client implementations
- Follows Specification: Empty lists are semantically equivalent to omitted fields
- Backward Compatible: Existing functionality remains unchanged
Impact Assessment
Benefits:
- Resolves parsing failures with Lighthouse beacon client
- Maintains strict validation of actual data entries
- No breaking changes to existing API
- Improves library robustness across different client implementations
Risks:
- Minimal - only relaxes field presence requirements while preserving data validation