search

monero-project / research-lab

A general repo for Monero Research Lab work in progress and completed work
238 stars 78 forks source link

Exploring Trustless zk-SNARKs for Monero's payment protocol #100

Open sethforprivacy opened 2 years ago

sethforprivacy commented 2 years ago

The goal of this meta issue is to build a go-to place for links, information, and opportunities for building trustless zk-SNARKs as a potential future protocol building-block for Monero.

Disclaimer: I am not a cryptographer or a dev, so please provide corrections and context if I have missed key details here. I am merely seeking to pull people together who are, provide resources, and ensure we take as close of a look as necessary at zk-SNARKs as a potential upgrade for Monero in the future.

Why zk-SNARKs?

Monero has iterated over the years to continue in leading the way in building out a cryptocurrency that puts user's privacy and security above all else. The Monero community has done this through finding the gaps and flaws in the protocol, watching external projects and researchers work, and implementing both internal and external developments over time to improve the holistic privacy provided to every user of the Monero network.

The weakest aspects of Monero's current approach to privacy is that of ring signatures, the approach that is taken to hide the true spend in each transaction among a set of potential signing inputs. These ring signatures have been an excellent tool for Monero so far, allowing us to build stable, efficient, and trustless privacy into each transaction, and are greatly strengthened by the added privacy of one-time addresses and confidential amounts.

While these three building blocks provide strong privacy today and show no signs of causing broad issues, they have noted weaknesses, especially for targeted threat models or those where multiple entities collude to form a transaction graph via EAE attacks or similar. This key weakness, combined with the ability to build probabilistic transaction graphs with off-chain data, should push us to keep seeking how we can mitigate the issue entirely.

The proposed Seraphis protocol allows us to greatly reduce the chances of successful probabilistic tracing, but is not necessarily a complete solution for targeted attacks or those aided by off-chain metadata. I do not want to prevent the further exploration of Seraphis with this effort, and a migration to Seraphis could even simplify a potential future migration to zk-SNARKs thanks to the modularity of Seraphis approach to the payment protocol.

zk-SNARKs allow us to move from obfuscating the true spend to truly hiding it, a large step forward in preventing even targeted attacks from building a transaction graph, while doing so in a way that remains trustless and efficient.

While it is outside of the scope of this issue, zk-SNARKs can also be used to build out much more advanced protocol features such as colored coins, smart contracts, etc. like currently being built out by DarkFi. This flexibility can pave the way for greater use-cases being built out on Monero in the future, and could be an extremely useful building block.

Why now?

With the advent of trustless and relatively efficient zk-SNARKs via advances like PLONK and implementations of it like Halo 2, zk-SNARKS are finally at a state where we can truly explore what an implementation of them in Monero's broader transaction protocol would look like, the implications it would have, the leg-work required, etc.

While Seraphis will bring much greater per-transaction graph obfuscation, it still provides some attack vectors for targeted attacks. As such, we should keep looking to the future and find ways that we can continue improving the Monero protocol over time.

Proposed efforts

While I know this is a major shift in the approach Monero has taken to output hiding in the past, there are some unique opportunities available to us today thanks to the wealth of effort being poured into zk-SNARKs across the cryptocurrency and privacy ecosystem today.

  1. Amir Taaki (@narodnik) of Dark.fi has offered to contribute whatever education/bootcamping is necessary to get Monero developers up to speed on implementing zk-SNARKs in a payment protocol
    1. Amir's estimate is ~2wks of full-time bootcamping to get up to speed and implement a PoC in a simple language
    2. I would love to see developers that are familiar with cryptography/math jump in on this and will help in crafting a CCS proposal for funding if necessary
  2. If necessary, I will organize a meeting of the MRL to discuss the viability of zk-SNARKs in the Monero protocol
  3. I will write up a blog post further outlining in laymen's terms why exploring zk-SNARKs as a replacement for ring-signatures (and likely confidential amounts) is an interesting and worthwhile topic to explore for the community (can publish on my own blog or getmonero.org if suitable)
  4. Collect feedback on ways that a migration to zk-SNARKs would effect current ecosystem participants, atomic swaps development, etc.

Open research questions

There are many open questions that we would need to (or should) answer in the process of exploring what an implementation of trustless zk-SNARKs would look like in Monero. If you want to take on one of these open questions, please open a new issue/gist and provide the link so I can update it here.

Extra notes

Helpful links

Educational resources and explainers

Existing implementations and code examples

P.S. -- if you come across helpful research that could be applicable to zk-SNARKs in Monero, please consider submitting it for inclusion on https://moneroresearch.info.

UkoeHB commented 1 year ago

We can also use one pair of membership proofs for every input, instead of per input. That'd make the second input add a few hundred bytes, not double the entire proof size. Unfortunately, I believe that breaks the flexibility of Seraphis a bit too much, with a notable privacy impact when TX-chaining/doing collaborative TXs (which are also how we start discussing payment channels, so I wouldn't appreciate so harming them).

If aggregating provides significant reductions in perf/size then we should definitely consider it.

UkoeHB commented 1 year ago

@tevador's short tower-cycle requires three relations for each of the three curves. Could the Wei25519 -> Eq relation be simplified by letting Eq be the leaf layer, and then doing a direct conversion to Wei25519 (via plain commitment to plain commitment instead of vector commitment to plain commitment)?

kayabaNerve commented 1 year ago

There's no change to perf. There is a significant reduction in size.

You'd need to promote a "Wei25519" key to Eq. While that can be down at time of tree addition, it can't be done at time of membership proof. The underlying point isn't available, only a blinded version, and whatever promotion occurs will remove the relationship of its blinding.

UkoeHB commented 1 year ago

You'd need to promote a "Wei25519" key to Eq. While that can be down at time of tree addition, it can't be done at time of membership proof. The underlying point isn't available, only a blinded version, and whatever promotion occurs will remove the relationship of its blinding.

I'm not sure what you're getting at here. Yes, the idea is to transmit Wei points into the tree during accumulation, then output blinded Wei points from the membership proofs.

There's no change to perf. There is a significant reduction in size.

This is a bit hard to believe, but will take your word for it until it's easier to evaluate.

kayabaNerve commented 1 year ago

1) If you promote Wei points at time of accumulation, so Ep points are the leaf layer, then at time of proof, you need to unblind the blinded Wei point into an Ep point. That requires unblinding as Wei, then performing the same promotion. The issue is that if there's an Ep leaf, there's an Eq proof, and with an Eq proof, Wei points aren't native so this would be extremely expensive.

2) Bulletproofs has O(n) verification time. While you save the BP setup costs, it doesn't change the total circuit size which is most of the expense. It's probably slightly more performant over all, though it does reduce the ability to batch a bit (as instead of 2 proofs with 512 shared generators, it's 1 proof with 1024 generators). Proof size is O(log n), so doubling the circuit size only adds 1 LR commitments (64 bytes). There's an extra couple hundred bytes on commitments but meh.

To discuss the short tower in more general, if we have Wei points as leaves, then the first proof would be Ep. Then the next Eq, and the cycle continues. The immediate issue is tevador's short cycle is slow.

The next issue is Ed25519 has torsion. I'm unsure the safety of that in the current proof, and I'm unsure the safety of divisors over torsioned curves. I believe the primary issue is the current on curve code expects points not to be identity, yet the small subgroup points would pass. While we can check that by doing 3 doubles, that'll take... 6 gates a point? And increase our proof size 10%. That ignores any larger safety concerns which may exist.

That also assumes we just to check isn't identity/small subgroup. If we have to check isn't torsioned, and we can't simply torsion clear, then the proof size will 3x. That'd be the worst case, yet immediately, the step would be to confirm the safety/applicability of divisors to torsioned curves. While we can drop divisors, that'd double the proof size.

And then long term, the issue is that the short tower cycle doesn't include Ed25519 scalars as a native field, solely Ed25519 field elements. The end goal of Monero should be each block, or the entire blockchain, having a single proof of range proofs for all prior TXs, either via Nova or Halo. If we do proofs over Ed25519, or Wei25519, then we can never have both fields natively available in a cycle.

TL;DR Would hurt perf by ~50%. Would need redone security analysis. At worst, it'll 2-3x our proof due to torsion. I'd guess it at least increases proof size 10% which will reduce the anonymity set to keep current perf. Long term, could make the only way to actually scale the Monero L1 multiple orders of magnitude less efficient.

chaserene commented 2 months ago

it's funny how this issue has been dormant while the biggest developments were taking place in the past month.

documenting the most important resources, as discussed in the 2024-04-24 MRL meeting:

tevador commented 2 months ago

This gist is also closely related to the current FCMP effort: Elliptic curve tower-cycle for Curve25519