What is Seraphis, and why should you care?
December 22, 2021
Seraphis is a ‘transaction protocol abstraction’ I’ve been working on (WIP draft document available here). As an ‘abstraction’, Seraphis defines rules on how to design a real (privacy-oriented) transaction protocol without specifying concrete algorithms. For example, RingCT is a different protocol abstraction (more or less), and there are several “real” versions that correspond to the signature schemes MLSAG and CLSAG. Seraphis is a candidate model for Monero’s next transaction protocol.
Privacy-oriented transaction protocols have two structural core rules.
- How are amounts displayed?
- How are key images (also called ‘linking tags’) constructed?
Since the introduction of RingCT, transaction protocols have had ‘hidden amounts’ using the Confidential Transactions technique (the CT in RingCT). However, key figures have seen recent innovations.
Triptych is a fourth-generation privacy-focused transaction protocol (following the Bitcoin, CryptoNote, and then RingCT models) with a new key image construct that enables “one-of-many proofs” (which behave similarly to ring signatures) with significant better performance for large reference sets (large numbers of decoys) compared to what is possible with CryptoNote / RingCT style key images. Note that while the Triptych paper does not distinguish between a ‘transaction protocol’ and a ‘transaction protocol abstraction’, Triptych represents a new abstract model that follows RingCT.
Seraphis is similarly a fourth-generation privacy-focused transaction protocol (abstraction). Like Triptych, it defines a new key image construct that allows efficient one-of-many proofing. However, there are some notable differences between Triptych and Seraphis.
Triptych vs. Seraphis
- Multisig is much more difficult with triptych style key images than with CryptoNote or Seraphis key images.
When thinking about a possible implementation…
- Multisig can be simple, similar to multisig with MLSAG/CLSAG.
- ‘Delegate Membership Certificate’ is possible without leaking users’ private keys. This may allow:
- Transaction chaining (required for full atomic swaps).
- Offload membership-proof construct to a third party, or a read-only wallet (possibly useful for spend-only hardware wallets where it is expensive/difficult to implement complex algorithms).
- Ignore 10-block lock time on trades with a trusted party (ie allow them to create your tx’s membership receipts and send the tx to the network on your behalf).
- Flexible multi-level address schemes. The following functions can be designed in a Seraphis user address scheme (there are at least 7 design variations, half of which require 3 key addresses [a 50% increase in address length over current addresses]):
- Wallet with display only that can see the issued output. Especially useful for multisig and hardware wallets, because in RingCT and CryptoNote it is necessary to constantly export key images.
- Display-only wallet that can see output received, but no amounts (and optionally can also see output spent, but no amounts). Useful for delegated chain scanning, where a third party or insecure machine scans for output and then sends it to a more secure 2nd-tier view-only wallet (or spend wallet) that can read the amounts.
- Read-only wallet that can detect the Janus attack.
- Modular core design. This will hopefully make it easier to upgrade different parts of a Seraphis implementation as innovations appear (or maybe we’ll be stuck for the next 20 years… who knows?).
- Not compatible with CryptoNote user addresses. If Seraphis is used to upgrade a cryptocurrency that has CryptoNote-style addresses, then users should replace all their CryptoNote-style public addresses with Seraphis-style addresses (they wouldn’t need new private keys or wallets).
What about Lelantus Spark?
Lelantus Spark is a transaction protocol (but not an abstraction – like how Triptych is not an abstraction) very similar to Seraphis, with the same pros and cons over Triptych. It was developed largely independently of Seraphis.
Since they were being developed at the same time, the question was ‘why Seraphis and not Lelantus-Spark?’ can be said just as easily ‘why Lelantus-Spark and not Seraphis?’ Practically speaking, the authors of Lelantus-Spark have focused their attention on design details suitable for the Firo cryptocurrency, while my design recommendations for Seraphis (in the paper) have focused on details suitable for a cryptocurrency that currently supports the RingCT standard. (such as Monero or MobileCoin).
post tags : Monero Research Lab, Community