StorageApplication


StorageApplication PI

Input

GitHub

pub struct StorageApplicationInputData<F: SmallField> {
    pub shard: UInt8<F>,
    pub initial_root_hash: [UInt8<F>; 32],
    pub initial_next_enumeration_counter: [UInt32<F>; 2],
    pub storage_application_log_state: QueueState<F, QUEUE_STATE_WIDTH>,
}

Output

GitHub

pub struct StorageApplicationOutputData<F: SmallField> {
    pub new_root_hash: [UInt8<F>; 32],
    pub new_next_enumeration_counter: [UInt32<F>; 2],
    pub state_diffs_keccak256_hash: [UInt8<F>; 32],
}

FSM Input and FSM Output

GitHub

Main circuit logic

This circuit takes storage requests from storage_application_log_state. Then for each query, it verifies the read value and updates the root_hash is needed. Also, it outputs the hash of storage diffs. Shard_id if enforces to be 0 for now, because we have only one shard.

First part

GitHub

The circuit begins with allocating input part of the PI.

We chose what storage_application_log_state, root_hash and other fields to continue to work with.

Main part

GitHub

Here’s the part, where all the main logic is implemented. Firstly, we take a new storage request if needed.

Now we can parse it and do some checks.

We need a merkle path for executing query.

Also, we update state_diffs data.

Finally, we compute a new merkle path.

If it was a write request, then we update the root_hash. Otherwise, we enforce that it’s still the same.

In the end, we update state_diffs state.

Final part

GitHub

We need to run padding and one more permutation for final output.

Now we update PI output parts and compute a commitment. Then we allocate it as public variables.

Last updated