Skip to content

Add SSZ Support#403

Open
jclapis wants to merge 95 commits intomainfrom
ssz-update-v2
Open

Add SSZ Support#403
jclapis wants to merge 95 commits intomainfrom
ssz-update-v2

Conversation

@jclapis
Copy link
Copy Markdown
Collaborator

@jclapis jclapis commented Nov 11, 2025

This is an update to #372 which is now obsolete, and adds robust SSZ support to get_header() and submit_block():

  • Support for multiple ACCEPT types
  • Support for dynamically converting SSZ requests when the relay only supports JSON
  • Ability to translate transparently from the type returned by the relay back to the type requested by the client (e.g. SSZ (client request) -> JSON (relay request / response) -> SSZ (client response))

eserilev and others added 30 commits February 5, 2025 13:37
Co-authored-by: eltitanb <lorenzo@gattaca.com>
Co-authored-by: ltitanb <163874448+ltitanb@users.noreply.github.com>
Co-authored-by: Manuel Iñaki Bilbao <manuel.bilbao@lambdaclass.com>
Co-authored-by: eltitanb <lorenzo@gattaca.com>
Co-authored-by: ltitanb <163874448+ltitanb@users.noreply.github.com>
Co-authored-by: Manuel Iñaki Bilbao <manuel.bilbao@lambdaclass.com>
Co-authored-by: eltitanb <lorenzo@gattaca.com>
Co-authored-by: ltitanb <163874448+ltitanb@users.noreply.github.com>
Co-authored-by: Manuel Iñaki Bilbao <manuel.bilbao@lambdaclass.com>
Co-authored-by: ltitanb <163874448+ltitanb@users.noreply.github.com>
Co-authored-by: eltitanb <lorenzo@gattaca.com>
Co-authored-by: ltitanb <163874448+ltitanb@users.noreply.github.com>
Co-authored-by: Manuel Iñaki Bilbao <manuel.bilbao@lambdaclass.com>
Co-authored-by: eltitanb <lorenzo@gattaca.com>
Co-authored-by: ltitanb <163874448+ltitanb@users.noreply.github.com>
Co-authored-by: Manuel Iñaki Bilbao <manuel.bilbao@lambdaclass.com>
Co-authored-by: ltitanb <163874448+ltitanb@users.noreply.github.com>
Co-authored-by: Manuel Iñaki Bilbao <manuel.bilbao@lambdaclass.com>
@jclapis jclapis mentioned this pull request Mar 2, 2026
@JasonVranek JasonVranek mentioned this pull request Mar 3, 2026
@JasonVranek JasonVranek requested a review from a team March 23, 2026 21:10
/// Which encoding types the original requester accepts in the response.
/// As the builder spec adds more encoding types, this struct can be expanded.
#[derive(Clone)]
pub struct AcceptTypes {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these seem to be unused, can delete? also we should have a clippy check that would flag things like that in CI

let (mux_lookup, registry_muxes) = match config.muxes {
Some(muxes) => {
let (mux_lookup, registry_muxes) =
let (mux_lookup, registry_muxes): (_, _) =
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can remove type annotation

let (mux_lookup, registry_muxes) = match cb_config.muxes {
Some(muxes) => {
let (mux_lookup, registry_muxes) = muxes
let (mux_lookup, registry_muxes): (_, _) = muxes
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here too


let parsed = match mt.essence().to_string().as_str() {
APPLICATION_OCTET_STREAM => Some(EncodingType::Ssz),
APPLICATION_JSON | WILDCARD => Some(EncodingType::Json),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is wildcard actually a valid json? should this match have two branches maybe: ssz <-> json?
there is a comment below that says "Assume missing Content-Type means JSON" too - ??

.ok()
}

/// Enum for types that can be used to encode incoming request bodies or
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: redundant comment


/// The accepted encoding types from the original request, ordered by
/// descending caller preference (q-value).
accepted_types: Vec<EncodingType>,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is max two values, right? can we actually get two accepted types and not one for a single request? if yes, can do an ArrayVec then, otherwise one value is enough


match code {
StatusCode::ACCEPTED => {
return Ok(SubmitBlockResponseInfo {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe do an option instead? too expensive for a dummy value

/// response, leaving the raw bytes intact for direct forwarding to the caller.
/// Used in `HeaderValidationMode::None` where expensive crypto/structural
/// checks are skipped.
async fn send_get_header_light(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like this does pretty much the same thing as the _full version, so the inside part of these can be extracted
can do single function returning the raw response_bytes + content_type + fork, with a single decode step driven by a flag for the full / light


/// Send and lightly process a submit_block request, minimizing the amount of
/// decoding and validation done
async fn send_submit_block_light(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here - some duplicate code with the send_submit_block_full that can be extracted

pub const CONSENSUS_VERSION_HEADER: &str = "Eth-Consensus-Version";

lazy_static! {
static ref SSZ_VALUE_OFFSETS_BY_FORK: HashMap<ForkName, usize> = {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't think we need a hashmap for this, performance-wise inlining the get_ssz_value_offset_for_fork should do better

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core Core part of the repo (signer, modules interface)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants