ZkApp Design
Off-chain Storage
The difference and also innovation of zkApps is their use of “off-chain execution and mostly off-chain state model”.
Off-chain execution means every operation is executed on the client machine and then verified by validators with ZK proofs.
For the off-chain state model, zkApps do not store data on-chain directly. Instead, data structures like arrays or key-value maps can be stored indirectly in a smart contract with by being wrapped in Merkle Tree data structures.
To allow the availability this off-chain storage, all information required to reconstruct the Merkle Trees are dispatched/emitted using the concepts of Actions/Events in zkApp, which allow the retrieval of those information through Mina's graphql endpoints.
Moreover, the implementation of the off-chain storage and the storage service for its reconstruction is open-source, allowing anyone to be able to build the Merkle Trees on their own to use the protocol without relying on any service.
Concurrent Actions
To solve the concurrency problems in Mina protocol, we utilizes the concept of Actions in zkApp with the following design. We defined the lifespan of an action in 3 states:
Dispatch - Action is initiated.
Rollup (optional) - Actions are compiled and prepared for processing.
Process - Action is executed and completed.
The transaction will be defined to have 4 statuses based on the lifespan of above action:
Tx Sent: Action is pending.
Tx Succeeded: Action is recorded.
Rollup Succeeded (optional): Action is compiled with others in a rollup.
Process Succeeded: Action is fully processed.
There are two primary approaches for implementing zkApps based on the processing needs:
Contiguous Processing: zkApps with actions that can be processed in a contiguous sequence within a single recursive proof. This approach does not require a separate roll-up step.
Non-Contiguous Processing: zkApps with actions that must be processed in non-contiguous sequences across multiple recursive proofs. These zkApps should utilize the shared RollupContract zkApp for the rollup step.
To not duplicate the task of roll-up, we create a shared contract, which facilitates the rollup process for zkApps by:
Recording actions dispatched by any zkApp.
Consolidating actions from all registered zkApps into a single transaction, updating to the latest action states.
This structure ensures efficient and organized processing of actions across multiple zkApps, optimizing transaction throughput and system scalability.
Last updated