StorageApplication
StorageApplication PI
Input
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
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
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
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
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
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