https://github.com/oxarbitrage/mini-zcash
A succint Zcash blokchain protocol
https://github.com/oxarbitrage/mini-zcash
Last synced: 6 months ago
JSON representation
A succint Zcash blokchain protocol
- Host: GitHub
- URL: https://github.com/oxarbitrage/mini-zcash
- Owner: oxarbitrage
- Created: 2024-12-05T18:58:06.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-04-10T15:29:08.000Z (over 1 year ago)
- Last Synced: 2025-07-11T04:39:35.527Z (about 1 year ago)
- Language: TLA
- Homepage:
- Size: 117 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Zcash Succint Protocol
This project models a theoretical **succinct version of the Zcash blockchain**, abstracting several components to achieve the following goals:
- **Constant storage** efficiency for all parties, regardless of the number of transactions or blocks.
- **Full privacy** using Zcash Orchard technology for transactions and efficient ZK-SNARK proofs.
- **Non-auditability**, focusing solely on the current state by using Merkle tree compact representations to store commitments and nullifiers.
- **Abstract consensus mechanism**, with the focus just on transaction verification and state updates.
## The protocol
The protocol consists of three processes:
- **User:**
- Create transactions and proofs.
- Sends transactions and proofs to the transaction pool.
- **Producer:**
- Gathers transactions and proofs from the transaction pool.
- Proposes blocks.
- **Node:**
- Verifies proposed blocks, transactions and proofs.
- Updates commitments and nullifiers.
- Discards the block after processing.
```mermaid
flowchart TD
USER[[USER]] --> |Create tx with proofs|txPool
PRODUCER[[PRODUCER]] --> |Propose block|blocks
NODE[[NODE]] --> |Update|commitments
NODE[[NODE]] --> |Update|nullifiers
txPool --> |Add Transactions|PRODUCER
blocks --> |Add block|NODE
PRODUCER --> |Remove transaction|txPool
NODE --> |Remove block|blocks
nullifiers --> |Balance|USER
commitments --> |Balance|USER
```
### Specification
The [specification](protocol.tla) is implemented as a PlusCal algorithm with accompanying TLA+ [definitions](definitions.tla). A [PDF]((protocol.pdf)) version of the specification is also available.
This model is a simplified version with just one user, the number of states equals the number of labels in the processes (`CreateTx`, `Mine`, and `Verify`), plus the `Init` and `Terminating` states generated by the model checker.
## Protocol properties
The goal is to prove some properties of the protocol. Some properties are proven using TLA temporal logic and checked by TLC, other properties are classical text proofs.
### Liveness
- `HeightAlwaysIncreases`: Ensure that the height of the blockchain always increases.
- `TransactionsEventuallyProcessed`: Ensure that all transactions are eventually processed.
### Safety
- `NoDoubleSpending`: Ensure that no double-spending occurs.
### Balances
**Property:** Users can independently retrieve their balances by querying the node and using their private keys. This process relies on the `noteCommitmentRoot` and `nullifierRoot` shared states to verify the inclusion and spent status of their notes.
**Proof:**
- Identifying Notes:
- Each note commitment is derived using the user's public key.
- The user queries the node for commitments associated with their public key.
- The node provides commitments and a zk-SNARK proof validating their inclusion in the `noteCommitmentRoot`.
- Verifying Spent Status:
- The user computes nullifiers for their notes.
- The user queries the node for nullifiers' inclusion in the `nullifierRoot`.
- The node provides a zk-SNARK proof verifying which nullifiers are spent.
- Computing Balance:
- The user sums the values of all unspent notes identified through these proofs.
### Storage
**Property:** The storage required for the node is constant over time.
**Proof:**
- Nodes discard proposed blocks after processing. At any given time, the storage required for proposed blocks is `O(MAX_BLOCK_SIZE)`.
- The blockchain maintains:
- `tip_block`: Requires `O(MAX_BLOCK_SIZE)`.
- `noteCommitmentRoot` and `nullifierRoot`: Fixed-size proofs, requiring `O(PROOF_SIZE)` each.
- Total storage complexity for the node is: `O(MAX_BLOCK_SIZE*2)+O(PROOF_SIZE*2)`.
This is constant regardless of the number of transactions or blocks.
### Non-auditable
**Property:** The protocol enables limited auditability, allowing users to audit their own balances and transaction history using their private keys, but prevents global auditability.
**Proof**:
- Retention of Compact State:
- The protocol retains only the `noteCommitmentRoot` and `nullifierRoot`, which summarize the current state of the system.
- Raw transactions, full Merkle trees, and intermediate states are not stored.
- User-Specific Auditability:
- Each user can use their private key to:
- Identify their notes within the commitments summarized by `noteCommitmentRoot`.
- Verify the spent status of these notes using `nullifierRoot`.
- Compute their balance and reconstruct their transaction history based on these proofs.
- No Global Auditability:
- Without access to the full tree structure or historical transactions, external parties cannot reconstruct the history of the blockchain.
- The zk-SNARKs ensure that only valid state transitions are recorded, but they reveal no details about the underlying transactions.