Function: update(bytes proof, uint256 newHead, byte[32] newHeader, byte[32] executionStateRoot, uint256 _executionBlockNumber, byte[32] syncCommitteeHash, byte[32] nextSyncCommitteeHash, StorageSlot[] _storageSlots)

This function is used to update the light client with a new header, execution-state root, and sync committee when it changes. All the inputs are verified against the proof provided, and the state of the light client is updated accordingly. In addition, the storage slots are updated with the provided values.

The proof is expected to be generated by the SP1 Helios light-client program, which is a zkSNARK program that verifies the validity of the new header, execution-state root, and sync committee against the previous state of the light client. The verifier key is expected to be LIGHT_CLIENT_ELF of the SP1 Helios light-client program.

Inputs

• proof

  • Control: Arbitrary.

  • Constraints: Verified in the verifier contract.

  • Impact: The proof bytes for the SP1 Helios light-client proof.

• newHead

  • Control: Arbitrary.

  • Constraints: Must be greater than the current head, divisible by 32, and a checkpoint slot, which is verified against the proof.

  • Impact: The slot of the new head.

• newHeader

  • Control: Arbitrary.

  • Constraints: None, but verified against the proof.

  • Impact: The new beacon block-header hash.

• executionStateRoot

  • Control: Arbitrary.

  • Constraints: None, but verified against the proof.

  • Impact: The execution-state root from the execution payload of the new beacon block.

• _executionBlockNumber

  • Control: Arbitrary.

  • Constraints: None, but verified against the proof.

  • Impact: The execution block number.

• syncCommitteeHash

  • Control: Arbitrary.

  • Constraints: None, but verified against the proof.

  • Impact: The sync-committee hash of the current period.

• nextSyncCommitteeHash

  • Control: Arbitrary.

  • Constraints: If the next sync committee is defined, it must match the expected value and be verified against the proof.

  • Impact: The sync-committee hash of the next period.

• _storageSlots

  • Control: Arbitrary.

  • Constraints: None, but verified against the proof.

  • Impact: The updated storage slots.

Branches and code coverage

Intended branches

• Call the verifier contract to verify the proof with inputs.

  Test coverage

• Update the light-client state with the new head, header, execution-state root, and sync committee.

  Test coverage

• Update the storage slots with the provided values.

  Test coverage

Negative behavior

• Revert if the sync committee for the current head is not set.

  Negative test

• Revert if the new head is behind the current head.

  Negative test

• Revert if the new head is not a checkpoint slot (divisible by 32).

  Negative test

• Revert if the next sync committee is defined but does not match the expected value.

  Negative test

Function call analysis

• ISP1Verifier(this.verifier).verifyProof(this.lightClientVkey, abi.encode(po), proof)

  • What does this do? The proof provided by the user is verified through the SP1 verifier contract along with the associated public values.

  • If the return value is controllable, how is it used and how can it go wrong? The verifier contract should be trusted, as it is a core part of the SP1 Helios light client. If the proof is invalid, it will revert.

  • What happens if it reverts, reenters or does other unusual control flow? Reverts from this call means that the proof is invalid, which is expected behavior.