Assessment reportsPublic findings
Back to Zellic siteBack
↗
Assessment reports>SP1 Helios>Threat Model>Component: light-client
GeneralOverview
Findings
Critical (1)
Medium (1)
Informational (3)
DiscussionLoss of the guardian role after calling the relinquishGuardian functionSuggestion for gas optimization
Threat ModelWhat are threat models?
SP1HeliosPrograms: sp1-helios-programComponent: light-clientComponent: storage
SP1Helios.sol
Audit ResultsAssessment Results

Component: light-client

Description

The light-client component is responsible for verifying the state transitions and proofs of the SP1 Helios program. It ensures that the proofs are valid and that the state transitions are executed correctly.

The states of updates and finality updates are provided from external resources, such as the beacon chain. It should be trusted that the inputs are valid and correctly formatted.

Inputs

  • encoded_inputs (Vec<u8>): Input data for the light-client program, which includes the state-transition proofs and the associated data. It will be passed by the sp1_zkvm::io::read_vec function and decoded into a ProofInputs struct.

pub struct ProofInputs { pub updates: Vec>, pub finality_update: FinalityUpdate, pub expected_current_slot: u64, pub store: LightClientStore, pub genesis_root: B256, pub forks: Forks, pub contract_storage: Vec, }

Outputs

  • proof_outputs (ProofOutputs): The output of the light-client program, which contains the results of the state transition and the verified proofs. It is later passed as an argument to the update function in the SP1Helios contract.

struct ProofOutputs { /// The previous beacon block header hash. bytes32 prevHeader; /// The slot of the previous head. uint256 prevHead; /// The anchor sync committee hash which was used to verify the proof. bytes32 prevSyncCommitteeHash; /// The slot of the new head. uint256 newHead; /// The new beacon block header hash. bytes32 newHeader; /// The execution state root from the execution payload of the new beacon block. bytes32 executionStateRoot; /// The execution block number. uint256 executionBlockNumber; /// The sync committee hash of the current period. bytes32 syncCommitteeHash; /// The sync committee hash of the next period. bytes32 nextSyncCommitteeHash; /// Attested storage slots for the given block. StorageSlot[] storageSlots; }

Expected behavior

  • Decode the encoded_inputs into a ProofInputs struct.

  • Get the initial sync committee, and save it to prev_sync_committee_hash.

  • Get the header and head from finalized_header of the beacon state.

  • Verify and apply all generic updates.

  • Verify the finality update.

  • Check that the new head is not greater than the previous head and that it is a checkpoint slot.

  • Commit new state root, header, and sync-committee hash.

  • Verify the storage slots against the contract's storage root.

  • Generate the ProofOutputs with the verified state root and storage slots.

Zellic © 2025Back to top ↑