Skip to content

Instantly share code, notes, and snippets.

@kayabaNerve
Created July 26, 2023 23:04
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kayabaNerve/97441ad851dc6e4d2a0b699f58a004f2 to your computer and use it in GitHub Desktop.
Save kayabaNerve/97441ad851dc6e4d2a0b699f58a004f2 to your computer and use it in GitHub Desktop.
Monero and Moving to a Curve Cycle

Personally, I believe not moving to a curve cycle may be the biggest failure possible with Seraphis, and I'd likely lose interest in further contributing to Monero.

The end goal of any protocol is properly and efficiently doing its stated goal. For Monero, we prioritize privacy, yet we always seek out the best ways to be private. This shows with us not adopting a trusted setup (offering constant-time verification of any statement of any complexity, yet not being verifiable), yet moving from Borromean signatures to Bulletproofs, and later Bulletproofs+. We value performance, yet not when it's unsafe.

Currently, the only known sublinear proofs either:

  1. Require pairing-based curves, whose security is an active discussion (notably, within the last decade they lost tens of bits)
  2. A curve cycle

While Monero can find efficient proofs without a curve cycle, as seen with Bulletproofs, and still implement Curve Trees without a curve cycle (the current best case for full-chain membership proofs), via tower-hashing points from Ed25519 to a curve cycle, this will create a fundamental bottleneck in our protocol under currently known theory. With a curve cycle, we obtain access to incrementally verifiable computation (IVC). IVC would let a transaction have a single proof for all inputs, with the cost of a single proof (and a logarithmic cost for the incrementally-added other inputs). Due to the structure of Curve Trees, an IVC scheme would also halve the current proof sizes/times (ignoring the logarithmic cost) for a single input. For a two-input transaction, it'd be roughly four times faster.

While that would obviously be great, it isn't necessarily a requirement for Monero's future. The reason I believe a curve cycle to be a requirement is due to the benefits not stopping there. In the future, block miners could produce a proof for all proofs in their block, drastically reducing block verification time. This could be extended to the entire blockchain history, allowing pruning all historical proofs* without any loss in security. It's with that future in mind I believe a curve cycle is necessary. Else, another project will build a just as private, more efficient, more scalable project which will handle more transactions and become a more private protocol. That protocol will become more worthy of being the private cryptocurrency we use on a day-to-day basis accordingly.

*Some historical proofs were hashed into the transaction hash and accordingly would remain needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment