manta-network / spec

Manta Protocol Specifications

Manta Protocol Specifications

These are the current specifications for the protocols in the Manta family:

Name	Status	Version
MantaPay	Testnet	v1.0.0
FeeRelay	Draft	N.A

spec's Issues

Fix Asset Variables

Do we need to add range checks for asset.id and asset.value?

Relayer Design

We would like to design relayers for truly anonymous transactions, relayers should:

• Collect unsigned transactions from end users
• Sign and send transactions on users behalf
• Charge user transaction fees and commission

Design constraints:

1. There should be incentive mechanism prevent relayers being DDoSed.
2. End users privacy is guaranteed, user's identity never gets leaked (assuming the end user can use a VPN or TOR), even the relayer is not honest.
3. Relayer should not be able to charge the end user commission if the transaction is not written on chain.

Transparent and Asset-Id-agnostic UTXOs

To support future protocols which modify UTXO assets in public and across several asset kinds, we want something like the following to replace the current UTXO:

struct Utxo {
    transparent: Asset,
    shielded: Asset,
    commitment: Commitment := commit(trapdoor, shielded),
}

note := encrypt(utxo.shielded)

where AssetId has a reserved value like 0 which is used as a placeholder for the ledger to modify. Given this design, the following are the only allowed cases:

1. Shielded: (transparent.id == 0) && (shielded.id != 0)
2. Fixed-Transparent: (transparent.id == shielded.id) && (transparent.id != 0)
3. Mutable-Transparent: (shielded.id == 0) && (shielded.value == 0)

NOTE: In the case of Mutable-Transparent we must have that shielded.value == 0 or else the ledger would not be able to safely modify the transparent part of the UTXO without the user creating hidden value when trying to spend a UTXO after the ledger modifies its AssetId type, say by some swap contract call.

---

Reference: https://hackmd.io/@bhgomes/BkfW7TtCt

Quasi-Commutative Accumulators

Quasi-commutative accumulators have the following property:

h(h(acc, x), y) = h(h(acc, y), x)

where acc is the accumulated value. In general, these can be used to build zero-knowledge sets (rather than zero-knowledge ordered sets like Merkle Trees).

One possible idea for a ZKP-friendly quasi-commutative accumulator is just elliptic-curve scalar multiplication:

x * (y * G) = y * (x * G)

where G is the accumulated value. The proof protocol for this accumulator is the following:

struct Proof {
    witness: Group,
    accumulator: Group,
}

fn prove_membership(item: Scalar, proof: Proof) -> bool {
    Group::scalar_mul(proof.witness, item) == proof.accumulator
}

In order to generate the proof for a given item, someone with access to all the items multiplies all the items except the one they want to prove into one (secret) witness.

fn generate_proof(base: Group, item: Scalar, other_items: &[Scalar]) -> Proof {
    let mut witness = other_items.iter().fold(base, Group::scalar_mul);
    Proof { accumulator: Group::scalar_mul(witness, item), witness }
}

Fast Recovery of Private Asset

As number of txs grows on chain, the time of recover private asset grows linearly. Despite this linear growth seems unavoidable, we might be able to using some bloom-filter like technic to quickly skip some blocks.

Add Comparision to Previous Protocols and State-of-the-Art

Add comparisons to the previous version of the MantaPay protocol, with one-time addresses, and the original zerocash spec which this is based on. It could also be instructive to compare to Zcash Sapling (or other versions), but we should avoid making a "sales pitch" in the spec as this is inappropriate.

Upper bound to the transaction amount

We would like to cap the transaction amount for regulation compliance and minimize user risk at the start stage.

This transaction amount should be a public input to the zk circuit. In the short term, this can be passed in during the configuration of the genesis. In the long term, this need to be generated by a price oracle (either a AMM or Chainlink styled price oracle).

Improvement on Spec

I suggest an update on the notation in Definition 4.1.7.

1. We need to specify the meaning of t, z, and w.
2. We need to use a consistent notation for t v.s. $I_i$, and $z$ v.s. $z_i$.
3. What is the meaning of "accumulated values" $z_i$ and $\texttt{current}(s_i)$? The text is not very self-explained.

Please see Definition 4.1.7 below.

Hierarchical Derived Key Specification

We are using a modified form of the BIP-44 specification for the hierarchical derived key scheme. Some questions to address:

1. Should we pick our own purpose ID?

We should also write a specification of this scheme into the Manta spec.

Wallet Specification

We need to add a specification for the wallet protocol (see manta-accounting/wallet for more details on the current implementation). It should involve the following conceptual pieces:

• Signer (access to sk)
• Prover (access to ak)
• Viewer (access to vk)
• Wallet (asks Signer for balance state and shielded addresses and asks Ledger for global state)
• Ledger (current state of global system)

The specification should be general and follow the API of the protocol, not the implementation details of how it is currently organized. This spec should be placed in its own document for now (we can think about how much should be merged into the MantaPay spec itself).

Possible Weak Privacy Leaks Due to Accumulator Check

Because we need to check that accumulator values match an existing valid state of the ledger (think Merkle Tree Root), knowing the value corresponding to a UTXO can narrow down the search space for brute force de-anonymization attempts. Here are some potential attacks:

1. Knowing the root pins down which shard the UTXO comes from. Early on in the chain this can be a privacy issue since shards may contain very few UTXOs. Because this can be tracked over time, a brute force attack can gain some advantage if it starts from the beginning of the chain.

   Potential Fix: Buffer the shards with some other UTXOs which cannot be distinguished from legitimate ones, reducing initial privacy leak.

2. Knowing the root also reveals if some transactions are grouped within one block. Blocks which create UTXOs and spend them right away removes one layer of indirection and allows UTXOs to be correlated beyond a single transaction. This can be detected if the root that was just created in the block is used in a later proof in the same block. This does not change if we allow for concurrent transactions, and even reduces the privacy by allowing transactions further in the past.

   Potential Fix: Unknown.

These attacks are independent of the zero-knowledge assumed by the protocol.

Append-Only Indexed Merkle Trees

For classic non-membership proofs in Merkle trees, one needs to maintain a sorted ordering for leaves. Instead, we can use a linked list at the leaf layer to get non-membership proofs without shuffling the leaves of the tree. See https://eprint.iacr.org/2021/1263.pdf. However, if we use this system naively, we need to update the linked list during each append which will reset all the hashes in the tree. We should find a safe way to include the indexing property without the overhead of recomputing hashes. Can we put an upper bound on the amount of computation on the append operation?