Thread:
This is very cool. What is the fall back option if all syncing service operators go offline?
Can zcash validators additionally perform this role?
I think I heard in an interview from Sean that Tachyon would change how we use 12-24 words seed. Are we planning to discontinue the use of 12-24 seeds phrases? Or I will still be able if i lose everything to just type in a 12 words in a new device and get going.
The entire point of Tachyon is to increase scaling, if it’s a regression (which it’s not designed to be) then Zcash simply wouldn’t adopt it.
I’m not sure if @ebfull has posted benchmarks yet but suffice to say the FUDers probably don’t understand how it works.
This account is likely an imposter.
Anyway, on the topic I want to say that I don’t think tachyon is a good idea. It has too many downsides. Some of which are a total deal breaker for me.
I don’t think it is a good idea to de-prioritize crosslink over this.
Just a clarification - Crosslink and Tachyon are separate efforts that don’t necessarily interact with each other with regards to roadmapping + timelines.
not the impression I got from reading the conversation on twitter. Mert has framed this multiple times as Crosslink being deprioritized in favor of Tachyon.
There is some truth to the idea, that you have to pick one or the other. They interact in terms of the technology they touch, because both are very profound changes to Zcash. The thing I disagree with though is to pick Tachyon over Crosslink. Currently there is no proof this concept actually works. There should be a proof of concept and a benchmark first before making a decision like this.
On the other hand, even without this there are so many downsides on a conceptual level that it is unclear if that would change anything.
It changes something if you want to support more transactions. Very roughly speaking, this is Mina + Zcash, with its advantages and drawbacks.
what is the TPS of mina?
TPS doesn’t really mean much for such chains, just like with real-life cash or anonymity set size in zcash.
of course it does. This is still a distributed system in the real world. There is a measurable throughput. This throughput seems rather low in the case of Mina.
Measured tps for sure since Mina is very much underused. Zcash has also a lot of unused capacity atm and Tachyon is unnecessary for now. But this is for the future. Like quantum resistance is for the far far future.
I don’t advocate prioritizing any of these. I’m just interested in where it goes from an educational perspective.
I don’t mean measured tps in the sense of how much is it actually used. I mean what is the capacity of the system.
found an answer in the mina subreddit.
It’s not correct. A block currently can fit at most 128 transactions (realistically less due to fee transfers to snark workers). Slot time is 3 mins but only 75% are expected to be filled so that’s an average of 4 mins per block or 240 seconds.
A max of 128 transactions every 240 seconds is 0.53 tps.
After the hard fork, it’s possible to batch many account updates into a single zkApp tx.
@hanh what are your thoughts on the oblivious syncing service? Do we have to assume: this service has to constantly update the “output not spent yet” proof over all of the blockchain history? This means all of the blockchain state still has to be archived and this service has to connect to the archival node and retrieve the history and then construct this proof continuously for each output.
It’s the batching that makes the scalability.
This means all of the blockchain state still has to be archived and this service has to connect to the archival node
AFAICT, the non-inclusion proof is going to be an important part of the new system. Currently, building this proof requires knowledge of every used nullifier. It is a very heavy computation (and why voting uses a registration window). But I hope Sean found a way to do it differently. I couldn’t figure it out from his posts.
I am concerned that this system puts the burden of keeping the transactions on the wallet holders. Considering how easy it is to misplace a seed phrase, it seems that preserving the transactions is a huge requirement.
Unclear how well this works in practice. In mina users have to pay 1 mina per account. Rolling up the state is not transparent to the developers / users. Take a look at how to program smart contracts on mina: Mina Action & Reducers Guide: Writing our own reducers | by ZkNoid | ZkNoid | Medium
The developer has to be very careful to handle this properly otherwise the actions can’t be aggregated and throughput suffers. It is unclear if users and developers are properly incentivized to handle this right. It seems like a headache to get this right and there is the tragedy of the commons that the app will most likely still work even if its not properly optimized.
same tbh. Given that knowledge of every used nullifier is still necessary, it seems a bit like responsibilities are shuffled around.
It is better than having every full node keep every nullifier. But I think Tachyon goes further by allowing recursive non inclusion proofs. I could be completely wrong, so better wait until it is released.
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.
tps?⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀