espresso_types/v0/
header.rs

1use committable::Commitment;
2use serde::{Deserialize, Serialize};
3use vbs::version::Version;
4
5use crate::{
6    v0_1::{self, ChainConfig},
7    v0_2, v0_3, v0_4, v0_5,
8};
9
10/// Each variant represents a specific minor version header.
11#[derive(Clone, Debug, Hash, PartialEq, Eq)]
12pub enum Header {
13    V1(v0_1::Header),
14    V2(v0_2::Header),
15    V3(v0_3::Header),
16    V4(v0_4::Header),
17    V5(v0_5::Header),
18}
19
20/// Enum to represent the first field of different versions of a header
21///
22/// In v1 headers, the first field is a ChainConfig, which contains either the chain config or its commitment.
23/// For versions > 0.1, the first field contains the version.
24///
25/// This enum has the same variant names and types in the same positions (0 and 1) as the Either enum,
26/// ensuring identical serialization and deserialization for the Left and Right variants.
27/// However, it will deserialize successfully in one additional case due to the Version variant.
28///
29/// Variants:
30/// - Left: Represents the ChainConfig variant in v1 headers.
31/// - Right: Represents the chain config commitment variant in v1 headers.
32/// - Version: Represents the versioned header for versions > 0.1.
33#[derive(Clone, Debug, Deserialize, Serialize)]
34pub(crate) enum EitherOrVersion {
35    Left(ChainConfig),
36    Right(Commitment<ChainConfig>),
37    Version(Version),
38}
39
40/// Headers with versions greater than 0.1 are serialized as `VersionedHeader` with the version field as `EitherOrVersion`.
41/// This ensures that the first field is deserialized as the `EitherOrVersion::Version` variant.
42/// This approach is necessary because `serde_flatten()` cannot be used with bincode,
43/// as bincode does not support the `deserialize_any()`.
44#[derive(Clone, Debug, Deserialize, Serialize)]
45pub struct VersionedHeader<Fields> {
46    pub(crate) version: EitherOrVersion,
47    pub(crate) fields: Fields,
48}
espresso_types/v0/header.rs

espresso_types/v0/
header.rs
