Tachyon addresses a completely different kind of scaling problem than Mina, and although both protocols use recursive SNARKs, they also use them for different purposes.
Mina is a succinct blockchain, meaning that the blockchain itself is proof-carrying data. Succinct blockchains address the problem of validating the ledger history: instead of downloading the history and validating the state transitions yourself, you download the current state of the network, construct a commitment to it, and download a short (constant size) recursive proof that a blockchain exists which produced that state. Given this commitment, the proof can be checked and the node can bootstrap onto the network trustlessly. Once in this state, a node can participate in consensus by processing transactions and even produce new versions of the succinct blockchain by computing new recursive SNARKs locally and distributing them to the network.
This is really cool and saves bandwidth, but in practice nobody really cares about trustless bootstrapping. In practice, everyone is perfectly satisfied depending on a checkpoint in the node software and/or downloading the current consensus state from an existing node (rather than the whole history), since it is optimistically valid and faults can be discovered and proven easily.
I would certainly love to make Zcash a succinct blockchain someday, so I’m not dissing the technology at all. I’m just identifying the problem it solves, and in my pragmatic view it is not something we care about addressing right now in Zcash, and it is not something Tachyon aims to implement. Some might counter that Mina solves another problem: making new blocks faster to validate! But this is orthogonal to using a succinct blockchain; we can achieve it with simple proof aggregation techniques – which is what we intend to do with Tachyon as well, also using recursive proofs.
The more difficult scaling issues that Tachyon does address have to do with the growth of the consensus state itself. Zerocash has an unfortunate scaling problem whereby the state grows linearly in the number of previous transactions because every node must perpetually track revocation tokens (nullifiers) to prevent double-spending. Even at a small number of TPS this produces a massive increase in the actively maintained state of all consensus nodes, and none of this can be pruned or archived by validators. Validators need to arbitrarily query this dataset for every new transaction. This negatively affects our ability to just dial up block sizes in Zcash, even if we manage to adopt more efficient consensus protocol and p2p network technologies.
Mina solves this problem by not using Zerocash at all; they use an account model which is not anonymous, and therefore the state growth scales with the number of users rather than the number of previous transactions. Zcash needs every transaction to be indistinguishable for privacy reasons, so we cannot use this shortcut here.
Instead, Tachyon addresses the problem by changing the way the Zerocash construction works. Nullifiers will now change over time (rather than staying static) and which nullifier is revealed depends on when your transaction is accepted to the blockchain. Validators must only maintain the leading edge of revealed nullifiers (to prevent duplicates in concurrent transactions) but can otherwise permanently prune the nullifiers and everything else about the Tachyon transaction history. This removes the main cryptographic bottleneck that remains in Zerocash’s protocol from the validators’ perspective.
The way this works in Tachyon without allowing double-spending is what requires recursive proofs, which is a separate use case for them than what Mina does. The user will recursively prove all of their “previous nullifiers” were not revealed in previous blocks, and reveal only the most recent nullifier(s) in their transaction. Because all of their nullifiers are unlinkable, they can outsource the generation of this proof to an untrusted third party service which never learns the nullifiers the user actually reveals on chain. (There are some other cool tricks and techniques that make all of this practical and efficient.)
Tachyon can only address the nullifier scaling issue from the perspective of active consensus validators. Since users (or the services they depend on) must still prove they have not previously spent their funds, and because this proof requires periodic synchronization with new blockchain history, there remains a data availability problem. Fortunately, this is a strict improvement on the status quo: 1) the problem is isolated to these short nullifier objects, 2) consensus validators are divorced from the availability problem, and 3) the cryptography used to prove non-membership of nullifiers in chain history doubles as a proof-of-replication protocol that can be used to address the DA problem in different ways. I’m looking forward to talking about this more in the future, but it’s not a concern of mine right now.
The more pressing concern is the UX implication for the removal of in-band secret distribution. Getting this right will be challenging, but we simply have no choice but to do it. The existing payment protocol does not scale well, and is not post-quantum private. We’ll have to find the best trade-off that creates a good experience for wallets without socializing the costs of secret distribution (and wallet backup and restore) via the blockchain.