Seraphis: What It Will Do for Monero

This post describes Seraphis, a set of transaction protocol structures and abstractions developed by pseudonymous research contributor koe for the Monero ecosystem, and with ongoing security analysis by pseudonymous contributor coinstudent2048.
We make some simplifications and omit certain technical details for the sake of clarity; for this reason, and because the design of Seraphis is still in progress, interested readers should refer to Seraphis documentation for the most up-to-date information.

Protocols like Bitcoin and Monero and others rely on a so-called "output model" of operation, where an output is a representation of value that can be transferred.
Transactions consume one or more outputs controlled by a sender, and generate new outputs directed toward recipients (or back to the sender as change); the transaction must balance in that consumed outputs must contain a total value exactly equal to the value in new outputs (plus a network-imposed fee).
In many protocols like Bitcoin, the value contained in an output is written in the clear, as is the recipient.
Furthermore, by looking at the blockchain, it is trivial to see if and when an output has been spent (that is, if it has been consumed in a later transaction, and which transaction spent it).

By contrast, protocols like Monero introduce a different design:

• Output values are hidden and not visible on the blockchain
• Recipient addresses are hidden by the use of a one-time addressing protocol
• Whether or not an output has been spent is obscured by the use of ambiguous signatures

The result is that, absent external information, it is difficult to determine whether a given output has been spent, what its value is, and who its recipient is.

The current Monero transaction protocol is called RingCT, and uses several cryptographic building blocks to achieve these design goals.

• Commitments hide amounts in a mathematically-useful way
• Range proofs prevent overflow that could inflate supply
• Linkable ring signatures provide signer ambiguity and prevent double-spend attempts
• Commitment offsets assert that transactions balance

These building blocks are carefully intertwined to build the RingCT protocol.

A useful property of the RingCT protocol is that some building blocks can be changed or upgraded in a way that keeps the overall design and properties intact, but that can provide efficiency or security improvements. In fact, these kinds of upgrades have occurred (or are planned to occur) several times in Monero's history. Range proofs in the original RingCT protocol were bulky and slow; they were later updated to a construction called Bulletproofs that made transactions smaller and faster with better security analysis, and are planned to be updated to a newer construction called Bulletproofs+ for even greater efficiency benefits.

A similar process was undergone with the linkable ring signature building block. In the original protocol, a construction called MLSAG was used. This was later updated to a newer construction called CLSAG that is faster, results in smaller transactions, and has better security analysis. An even newer linkable ring signature construction based on Triptych was proposed, but this was not selected for deployment because of its impacts on multisignature operations.

Seraphis takes this idea a step further.
Rather than update individual building blocks of the existing RingCT transaction protocol, it introduces a different protocol that can take advantage of different building blocks and offer improved functionality.

Seraphis uses a different set of cryptographic building blocks to achieve its design goals.

• Commitments still hide amounts
• Range proofs still prevent overflow and supply inflation
• Membership proofs provide signer ambiguity
• Commitment offsets still assert balance
• Authorizing proofs prevent double-spend attempts

Notice the change here: linkable ring signatures are replaced with a combination of membership proofs and authorizing proofs. Roughly speaking, membership proofs show that a consumed output is part of a larger set, similar to what happens in RingCT. But unlike RingCT, membership proofs don't involve the linking tag at all! Authorizing proofs show that the linking tag is valid and are used to sign the final transaction.

Because RingCT bakes the linking tag into the ambiguous signature, signing (and multisignature) operations are more computationally intensive, and it becomes more challenging to build other tag-related functionality. But in Seraphis, constructing membership proofs can be safely delegated from highly trusted devices (which may have limited computing power, like a hardware wallet) to a less trusted device, and signing (and multisignature) operations are far easier using the much simpler authorizing proof.

Fortunately, some of the building blocks required by Seraphis already exist elsewhere, and don't need to be designed from scratch. Both the Bulletproofs and Bulletproofs+ constructions can be used as range proofs. Modifications to Schnorr-type proving systems can be used for authorizing proofs. And an efficient proving system used already as the basis for Triptych, Lelantus, and Spark^* can be modified for membership proofs.

^* Cypher Stack receives funding for Spark development.

Unfortunately, Monero addresses currently in use are not compatible with Seraphis. Users would need to generate new addresses from their wallet keys in order to receive Monero if Seraphis were implemented. However, this ecosystem cost comes with a host of benefits.

Aside from the structural benefits discussed above, the Seraphis design is amenable to many different address construction possibilities, each of which comes with tradeoffs. While the final address construction to be used in Seraphis is still being decided (one scheme receiving a lot of attention is called JAMTIS), we can describe some common and useful features.

You might know that Monero addresses offer view key functionality, where you can provide a view key to a device or third party and allow it to watch for incoming outputs on your behalf, but without giving up spend authority. This is useful for wallets, which can stay updated while keeping your spend key safely locked away. It's also useful for cases where you want external view access, like a public charity offering transparency or a company with an accounting department.

The downside to Monero view keys is that they don't provide complete or fine-grained view access. It's not possible to reliably detect when a wallet spends funds, which makes it difficult to compute wallet balances properly when the spend key isn't available. It's also not currently possible to detect incoming outputs without also learning the value contained in those outputs (which means any third-parties responsible for finding incoming outputs will learn exactly how much Monero you are acquiring).

Seraphis addressing constructions can solve this. With Seraphis, your address comes equipped with different keys that can do different things:

• Watch for incoming outputs, but hide their value
• Watch for incoming outputs, but show their value
• Watch for outgoing outputs
• Help you to generate transactions, but not sign them
• Generate new addresses (useful for retailers or exchanges with many customers)

As the address holder, you get to decide how much authority you delegate to other devices or third parties.

Seraphis is a major change to the Monero ecosystem. While it involves modifications to addresses and transaction building blocks, its design offers flexibility and useful functionality that aren't possible with today's RingCT protocol. While much of the design is finalized and being developed into an implementation, address design and security analysis are ongoing. Seraphis offers an excellent opportunity to push the Monero ecosystem forward!