Reconsider stack-allocated `Blob`/`Cell`

[michaelsproul]

Gattaca have noted that our Blob type is slower to SSZ decode than [u8; 128k]:

• Builder bid ssz decoding too expensive gattaca-com/helix#217

The reason seems to be that our Blob is heap-allocated:

lighthouse/consensus/types/src/lib.rs

Line 274 in cfb1f73

pub type Blob<E> = FixedVector<u8, <E as EthSpec>::BytesPerBlob>;

The slowdown looks crazy on a % basis, but is very small in absolute terms. 5us vs 800us. It's less than a millisecond spent decoding objects that takes 10s-100s of milliseconds to verify.

I think we originally put blobs on the heap to avoid stack overflows caused by deeply nested futures? But my memory of this is a bit hazy. If it turns out that we don't need to do this, we could reconsider using stack-allocated blobs (or, realistically just Cells).

This could be related to:

• Debug slow get_header overhead #7941

I'll look at that next.

[michaelsproul]

Funnily enough, we can speed up decode times to be competitive with the stack-allocated bytes by using a simpler specialised implementation of Decode:

#[derive(Clone, Debug, Default, PartialEq, Eq, ssz_derive::Encode)]
#[ssz(struct_behaviour = "transparent")]
pub struct NuBlob(FixedVector<u8, <MainnetEthSpec as EthSpec>::BytesPerBlob>);

impl ssz::Decode for NuBlob {
    fn is_ssz_fixed_len() -> bool {
        true
    }

    fn from_ssz_bytes(bytes: &[u8]) -> Result<Self, DecodeError> {
        // This is where the speedup comes from. Just copy the bytes!
        FixedVector::new(bytes.to_vec())
            .map(Self)
            .map_err(|e| DecodeError::BytesInvalid(format!("{e:?}")))
    }

    fn ssz_fixed_len() -> usize {
        <FixedVector<u8, <MainnetEthSpec as EthSpec>::BytesPerBlob> as ssz::Decode>::ssz_fixed_len()
    }
}

I benchmarked this in Helix's repo just now and the bid now decodes in 3-3.7us (on my M1 Pro).

This means the slowness isn't from the allocation, but all of the bounds-checking and Vec::push stuff that we do to handle the generic case (FixedVector<T>):

https://github.com/sigp/ssz_types/blob/3f3d7de5677f5b923214e8b6b4c65b40566d6da4/src/fixed_vector.rs#L303-L327

[michaelsproul]

To get this benefit in LH we'd have to change Blob and Cell to newtypes rather than type aliases, and implement Decode manually for them.

[michaelsproul]

Another potential target:

lighthouse/consensus/types/src/execution_payload.rs

Line 9 in cfb1f73

pub type Transaction<N> = VariableList<u8, N>;

I've definitely seen EL payload hashing show up in profiling before, I think I've seen decoding as well.

[paulhauner]

Perhaps ssz_types could implement and export a FixedVectorU8<N> and a VariableListU8<N>.

Sounds like it would be simple enough and widely useful as a drop-in replacement.

[michaelsproul]

Perhaps ssz_types could implement and export a FixedVectorU8 and a VariableListU8.

Yeah I think this is the best option to make this optimisation widely available! I didn't think of it initially!

I'm kind of confused why the Rust compiler can't optimise our existing Decode impl. I'm going to take a quick look at that, because I think avoiding adding new types might be better for UX (we would have to proxy all their methods, use deref, or access the "true" list via a field).

[paulhauner]

I'm kind of confused why the Rust compiler can't optimise our existing Decode impl.

That definitely sounds like the ideal option. If that doesn't work, here's the specialised types imp: sigp/ssz_types#54

[ltitanb]

Another alternative could also be to add a fast path for u8 inside the existing FixedBytes<T, N>, using TypeId (though it does add a few bounds on T)

if TypeId::of::<T>() == TypeId::of::<u8>() { .. }

[michaelsproul]

My efforts here:

• Optimise SSZ encoding and decoding ssz_types#55

The type ID fast path might be the best (simplest) option, although I think it will require unsafe to transmute &[u8] to &[T].