|
| 1 | +//! Unified transaction representation for SNARK circuits |
| 2 | +//! |
| 3 | +//! This module provides a single, unified structure ([`TransactionUnion`]) that |
| 4 | +//! can represent all transaction types (payments, stake delegations, fee |
| 5 | +//! transfers, coinbase) for SNARK circuit processing. This enables efficient |
| 6 | +//! proof generation by using a single circuit design regardless of the specific |
| 7 | +//! transaction type. |
| 8 | +//! |
| 9 | +//! # Transaction Union |
| 10 | +//! |
| 11 | +//! The [`TransactionUnion`] type encodes all transaction variants using a |
| 12 | +//! tagged union approach: |
| 13 | +//! |
| 14 | +//! - [`Common`]: Fields present in all transactions (fee, nonce, memo, etc.) |
| 15 | +//! - [`Body`]: Transaction-specific fields with interpretation based on [`Tag`] |
| 16 | +//! - [`Tag`]: Discriminates between Payment, StakeDelegation, FeeTransfer, and |
| 17 | +//! Coinbase |
| 18 | +//! |
| 19 | +//! # Field Interpretation |
| 20 | +//! |
| 21 | +//! Fields in [`Body`] are interpreted differently based on the [`Tag`] value: |
| 22 | +//! |
| 23 | +//! - **Payment**: `source_pk` and `receiver_pk` are sender and recipient |
| 24 | +//! - **Stake Delegation**: `receiver_pk` is the new delegate |
| 25 | +//! - **Fee Transfer**: `receiver_pk` is the fee recipient, `amount` is the fee |
| 26 | +//! - **Coinbase**: `receiver_pk` is the block producer, `amount` is the reward |
| 27 | +//! |
| 28 | +//! # Receipt Chain Hash |
| 29 | +//! |
| 30 | +//! This module also provides functions for computing receipt chain hashes, |
| 31 | +//! which commit to the sequence of transactions applied to an account: |
| 32 | +//! |
| 33 | +//! - [`cons_signed_command_payload`]: Updates receipt chain hash for signed |
| 34 | +//! commands |
| 35 | +//! - [`cons_zkapp_command_commitment`]: Updates receipt chain hash for zkApp |
| 36 | +//! commands |
| 37 | +//! - [`checked_cons_signed_command_payload`]: Checked version for use in |
| 38 | +//! circuits |
| 39 | +//! |
| 40 | +//! # Timing and Vesting |
| 41 | +//! |
| 42 | +//! The module implements timing validation for timed (vested) accounts: |
| 43 | +//! |
| 44 | +//! - [`validate_timing`]: Ensures timing constraints are met for an account |
| 45 | +//! deduction |
| 46 | +//! - [`validate_nonces`]: Validates transaction nonce matches account nonce |
| 47 | +//! - [`account_check_timing`]: Checks timing status for an account |
| 48 | +//! - [`timing_error_to_user_command_status`]: Converts timing errors to |
| 49 | +//! transaction failures |
| 50 | +//! |
| 51 | +//! Timed accounts have a minimum balance that decreases over time according to |
| 52 | +//! a vesting schedule. When the minimum balance reaches zero, the account |
| 53 | +//! automatically becomes untimed. |
| 54 | +//! |
| 55 | +//! # Account Helpers |
| 56 | +//! |
| 57 | +//! Utility functions for account operations: |
| 58 | +//! |
| 59 | +//! - [`get_with_location`]: Retrieves an account or creates a placeholder for |
| 60 | +//! new accounts |
| 61 | +//! - [`ExistingOrNew`]: Indicates whether an account exists or is newly created |
| 62 | +//! - [`add_amount`]/[`sub_amount`]: Safe balance arithmetic with |
| 63 | +//! overflow/underflow checking |
| 64 | +
|
1 | 65 | use super::{ |
2 | 66 | signed_command::{ |
3 | 67 | self, PaymentPayload, SignedCommand, SignedCommandPayload, StakeDelegationPayload, |
|
0 commit comments