Function: updateStorageSlot(bytes proof, StorageSlot[] _storageSlots, uint256 blockNumber)

This function verifies a storage-slot proof and updates the storage slots in the contract. It uses the provided proof to verify the storage slots against the execution-state root for the given block number. If the proof is valid, it updates the storage slots in the contract.

The proof is expected to be generated by the SP1 Helios storage-slot proof program, which is a zkSNARK program that verifies the validity of the storage slots against the execution-state root. The verifier key is expected to be STORAGE_ELF of the SP1 Helios storage-slot proof program.

Inputs

• proof

  • Control: Arbitrary.

  • Constraints: Must be a valid proof for the storage slots against the execution-state root.

  • Impact: The proof bytes for the SP1 storage-slot proof.

• _storageSlots

  • Control: Arbitrary.

  • Constraints: None, but verified against the proof.

  • Impact: The storage slots to verify and update.

• blockNumber

  • Control: Arbitrary.

  • Constraints: None, but verified against the proof.

  • Impact: The block number of the storage slot, used to compute the storage-slot key.

Branches and code coverage

Intended branches

• Invoke verifyStorageSlotsProof to verify the proof with inputs.

  Test coverage

• Update the storage slots with the provided values.

  Test coverage

Negative behavior

• Revert if the execution-state root for the given block number is not set.

  Negative test

Function call analysis

• this.verifyStorageSlotsProof(proof, _storageSlots, blockNumber) -> ISP1Verifier(this.verifier).verifyProof(this.storageSlotVkey, abi.encode(sspo), proof)

  • What does this do? Verifies the storage-slot proof against the execution-state root for the given block number.

  • If the return value is controllable, how is it used and how can it go wrong? N/A.

  • What happens if it reverts, reenters or does other unusual control flow? If the execution-state root corresponding to the block number specified by the user cannot be retrieved from the contract, the call will revert and the update to the storage slot will fail.

• ISP1Verifier(verifier).verifyProof(storageSlotVkey, abi.encode(sspo), 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.