Tachyaction at a Distance

This blog post is intended for Zcash protocol developers. Reader discretion is advised.

🔗

Tachyon fully embraces out-of-band payments for the first time in a Zcash shielded protocol. This is being done to ensure the protocol can plausibly scale, but comes with some consequences for the user experience surrounding payments. I'll be discussing that in more detail in a future blog post, but for now it is fun to glimpse at what the protocol looks like in the absence of in-band secret distribution.

In many ways the protocol becomes simpler and begins to resemble the original Zerocash construction. However, Tachyon still preserves some of the ideas we deployed in the Orchard shielded protocol: in particular, we'll still use RedPallas key re-randomization, homomorphic value commitments and binding signatures, and a partitioned key structure that allows proof delegation without conferring spend authority.

The two other prongs of Tachyon's design are more complicated and involve novel ideas and clever cryptography: oblivious synchronization and shielded transaction aggregates. These have some non-trivial impacts on the transaction model that relate to how signing works and how shielded state changes are communicated in the protocol.

I'll dive into those topics in their own blog posts as well, but we can begin to sketch their effects on the larger protocol as far the the consensus protocol is concerned.

🔗Turnstiles

First, a disclaimer. Tachyon is a reverse-compatible change to the Orchard protocol.

Tachyon can be integrated into the Zcash protocol either as an upgrade to the existing Orchard shielded pool or as a standalone shielded pool by incorporating a turnstile. There are positive and negative consequences for either deployment path. I'll be discussing this in more detail very soon, but the deployment strategy does not influence any of the design decisions for Tachyon mentioned in this blog post.

🔗Simpler Foundations

Tachyon removes in-band secret distribution, meaning the Zcash blockchain cannot be (easily) used to communicate with your counterparty or store/share wallet information. This requires those functions to exist in a higher-level protocol supported by your wallet.

As a consequence nearly all of the design complexity of the key derivation tree is punted out of the core protocol and out of the zk-SNARK circuits.

🔗

This removes key diversification, viewing keys, and even payment addresses. “Payment keys” in Tachyon are used by wallet software as part of a larger protocol such as a payment request or a URI encapsulated payment. We still have some structure in this reduced form of the protocol, mainly to separate the capability to construct proofs () from the ability observe when funds are spent () or to authorize the spend of funds ().

The simplified key structure makes shielded notes simpler as well. Recall that in Orchard they are defined as:

Tachyon removes the diversifier because payment addresses are removed. The transmission key is substituted with a payment key . The unique value is no longer needed because Tachyon does not need to defend users against “faerie gold” attacks.¹

This means that Tachyon's notes are simpler:

Besides the payment key and note value the note only contains a nonce and a commitment key , both of which could be derived from a shared key that is negotiated through the out-of-band payment protocol.

Tachyon nullifiers are derived and handled differently by the protocol due to oblivious synchronization. Consensus validators only need to retain the last blocks worth of nullifiers and reject transactions that reveal duplicate nullifiers within this range, after which older nullifiers can be pruned permanently by the validator. In exchange users are required to prove their notes were spendable up until a recent point in the history of the chain (well within blocks).

Users will outsource the creation of these proofs to an untrusted third party called an “oblivious syncing service” that does not learn about the user's wallet or transactions. In order to achieve this strong privacy guarantee all nullifiers in Tachyon have an additional component that I'll call “flavor” for now. In a future blog post on oblivious synchronization I will elaborate over the mechanics of this derivation.

Together with the changes to the notes, nullifiers in Tachyon can be massively simplified. Orchard defines nullifiers as:

where is a keyed PRF; Orchard uses Poseidon for this purpose.

There is a great explanation for the complexity in the Orchard book, but the design boils down to countering faerie gold attacks and making weak assumptions about circuit-efficient PRFs. As mentioned, is removed from notes. Also, oblivious synchronization will not support the previous arrangement involving the note commitment ().

Tachyon should settle for a simpler nullifier:

with being a keyed PRF we're comfortable with.² The selection of primitives amongst the trade-off space will be a delightful conversation to have later in the design process. The many years that have elapsed since Orchard's design (and the more forgiving environment of non-uniform circuits in proof-carrying data constructions) should give us more options and confidence this time around.

🔗Tachygrams, Tachystamps, and Tachyactions

The consensus protocol does not need to distinguish between Tachyon's nullifiers and note commitments that are revealed in blocks — they are treated identically as 32-byte blobs that are recorded in the blockchain. Let us refer to these generally as “tachygrams.”

The purpose of this unification is to simplify the protocol: there's no pressing need to distinguish between the two for performance reasons, and their unification allows a single accumulator to be used both for membership and non-membership proofs. Although not a goal, this unification may naturally result in their indistinguishablity.

Tachyon allows Spend and Output operations to occur independently of each other, similar to Sapling³, except that their behavior is also unified: regardless of the operation a pair are produced. The operation is authorized by with a RedPallas signature in a manner that depends on the context supported by the protocol.

This arrangement deliberately allows the tachygrams to exist independently of the transaction. In order to bind the signature digest⁴ with the tachygrams the re-randomization of and the key for the commitment are themselves (nested) commitments to the note commitment being created or spent.

🔗

Finally, a “tachystamp” is produced. Tachystamps are proof-carrying data (PCD): they contain a list of tachygrams, an identifier similar to an anchor⁵, and a recursive SNARK. The associated material for each operation is needed to verify the tachystamp.

Tachystamps, being PCD, can be combined together so that a transaction (or ultimately, an entire block) contains just one recursive SNARK. Block creators can merge tachystamps together into shielded transaction aggregates and replace the tachystamps in transactions with references to the aggregate(s) that subsume them, because they are strictly authorizing data.

Some will point out that we can be more aggressive here and aggregate the signatures as well, but this opens a can of worms early in the protocol design without a significant benefit. Fully shielded transactions can theoretically exist entirely within an aggregate without a host transaction, which should perhaps be the focus of these kinds of optimization efforts.

🔗Tachyactions

Tachyon bundles work similar to the existing Orchard bundles except that “tachyactions” replace (or augment) the traditional Orchard actions.

🔗

The field in bundles can be omitted in the absence of traditional Orchard actions. As mentioned, a tachystamp also exists in the bundle (as authorizing data) in the presence of any tachyactions, although it can be replaced with a reference to an aggregate.

---