Writing ZKWASM Application
Here we using the previous template (can be find at "https://github.com/DelphinusLab/zkwasm-mini-rollup/blob/main/abi/src/lib.rs") to demonstrate the key concept of customizing your own rollup application.
As has said before, the core step of the service is handle_tx
, in which the server handles the user request and updates the global state (Merkle tree). Before handle_tx
the server needs to check that the signature of the transaction is valid. Thus the core steps based on handle_tx
will be the following three:
params preparation for the transaction
verification of the signature
handle the transaction
Params preparation
In this tutorial, we assume that the inputs of a trasaction contains three parts. The first part is the user ID which is the publication key (input[0..8]
). The second part is the signature of the transaction (input[8..20]
) and the last part is the transaction inputs provided by the user (input[20..]
). Since all the params are reading from the private inputs, it is read by zkwasm_input(0)
as follows.
Signature verification
A reference implementation of verify_tx_signature
can be found in https://github.com/DelphinusLab/zkwasm-mini-rollup in which the altjubjub curve is used. The convention is simple that the inputs(input[20..]
) of the transaction are hashed to be the message of the signature.
Transaction handling
When handling the transaction, the handler changes the global state and produces a few settlement events. The changed state will be the initial state for the following transactions but the settlement events are accumulated until the preemption point is reached. Once the preemption point is reached, all settlement events will be flushed and hashend to form a pineed receipt. This receipt plus the merkle root before and after the execution will be the public input of the bundled execution.
handle a single transaction
encode bytes of settlement events into wasm output
bind the inputs and outputs of the execution
Last updated