These are the current specifications for the protocols in the Manta family:
Name | Status | Version |
---|---|---|
MantaPay |
Testnet | v1.0.0 |
FeeRelay |
Draft | N.A |
Manta Protocol Specifications
Home Page: https://github.com/Manta-Network
License: GNU General Public License v3.0
Do we need to add range checks for asset.id
and asset.value
?
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:
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.
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.
As number of tx
s 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.
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 }
}
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:
sk
)ak
)vk
)Signer
for balance state and shielded addresses and asks Ledger
for global state)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).
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.
We would like to design relayers for truly anonymous transactions, relayers should:
Design constraints:
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:
(transparent.id == 0) && (shielded.id != 0)
(transparent.id == shielded.id) && (transparent.id != 0)
(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
We are using a modified form of the BIP-44 specification for the hierarchical derived key scheme. Some questions to address:
We should also write a specification of this scheme into the Manta spec.
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).
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?
I suggest an update on the notation in Definition 4.1.7.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.