Validity conditions
The validity conditions of a transaction define when a transaction object is valid. Nodes should check the validity of a transaction when they receive it either directly or through the p2p pool, and if they find it to be invalid, should drop it immediately and not broadcast it.
In addition to being well-formed, the transaction object needs to pass the following checks:
- Proof is valid: The
proof
for the given publicdata
should be valid according to a protocol-wide verification key for the final private kernel circuit. - No duplicate nullifiers: No
nullifier
in the transactiondata
should be already present in the nullifier tree. - No pending private function calls: The
data
private call stack should be empty. - Valid historic data: The tree roots in the block header of
data
must match the tree roots of a historical block in the chain. - Maximum block number not exceeded: The transaction must be included in a block with height no greater than the value specified in
maxBlockNum
within the transaction'sdata
. - Preimages must match commitments in
data
: The expanded fields in the transaction object should match the commitments (hashes) to them in the publicdata
.- The
encryptedLogs
should match theencryptedLogsHash
andencryptedLogPreimagesLength
in the transactiondata
. - The
unencryptedLogs
should match theunencryptedLogsHash
andunencryptedLogPreimagesLength
in the transactiondata
. - Each public call stack item in the transaction
data
should have a corresponding preimage in theenqueuedPublicFunctionCalls
. - Each new contract data in transaction
data
should have a corresponding preimage in thenewContracts
.
- The
- Able to pay fee: The fee can be paid.
Note that all checks but the last one are enforced by the base rollup circuit when the transaction is included in a block.