Now we’re on the same page; so we need volume. I say trustless bridge and there’s one actual option to get there. What do you say would have the best potential going forward, L2?
Short and medium term, bridging. Long term (10-15 years from now), L2.
How does it look like technically? JAM / Hyperbridge network is what seem to be an interesting path, do you know of another trustless option? Personally I am absolutely against non-trustless now that trustless options exist.
IBC is the most popular trust-minimized bridging protocol
1 Like
Not the path I’m looking for but a path nonetheless; thank you for sharing your views on all this.
I’m only going to address the technical and engineering parts of this; the rest are endlessly debatable:
It is possible to get to ZSAs + private programmability (similar to the Hawk paper). I’m quite keen on that because I think it unlocks an immense range of use cases. I have previously been skeptical of programmability because I considered the attack surface to be too large. However, I’ve recently been convinced that advances in the accessibility of formal verification could enable smart contracts with high assurance of correctness and security.
In order to get there, one of ZSAs and programmability must come first; it wouldn’t be feasible or safe to do both at the same time. In practice, ZSAs have to come first because they are nearly ready, and programmability is not. Programmability likely also has a dependency on the Ragu recursive proving system being developed for Tachyon.
Yes. I think it’s worth it. As I’ve advocated since launch, we need to remove old shielded pools in order to keep protocol complexity and attack surface under control. We also needed to remove zcashd. This gives some headroom to increase complexity in other areas.
Stablecoin issuers won’t get those features. If that means centralized stablecoins are not implementable, so be it. I think algorithmic stablecoins are still feasible.
This is probably the strongest argument against, but I personally think that ZSA support is likely to improve adoption.
14 Likes
The sunk cost fallacy is a cognitive bias towards behaving as though past expenditures can be recovered when they cannot.
It is entirely reasonable to recognize and take into account the value of the product of already paid-for work. The proponents of ZSAs are not saying that the expenditure on ZSAs can be recovered. They are saying that the product of that expenditure should be used, because it has benefits that are now available very cheaply. That isn’t a fallacy.
Other positive arguments against ZSAs may exist but that is separate from the claim that proponents are committing a “sunk cost fallacy”, and IMHO shouldn’t be confused with it. I don’t believe they are committing that fallacy, I believe that opponents and proponents just have different assessments of the potential benefits and detriments of the existing (partially reviewed) work product, or of the remaining costs to complete it.
12 Likes
That isn’t true. ZSA notes (or Orchard actions involving them), are indistinguishable from ZEC notes (or Orchard actions involving them), provided that v6 transactions are used. ZIP 230 insists that all wallets SHOULD switch to v6 transactions without delay.
To me, this indistinguishability is an absolutely critical part of the design and I insisted on it. Without it, most ZSA assets would have a uselessly small note traceability set. With it, ZSAs add to the ZEC note traceability set and vice versa.
13 Likes
This is a perfect example of why AI is currently nowhere close to being able to accurately extract summaries of complex technical arguments. If wrong assertions are made, it values them the same as correct ones, because it doesn’t have sufficient context and is incapable of actually understanding the underlying technology.
(In this case, it doesn’t help that the concept of “anonymity set” is muddled and too imprecise to capture the relevant privacy properties in this setting. Anonymity set of what? That’s why I use “note traceability set” which is defined in the high-level overview section of the protocol spec.)
7 Likes
Does ZSA go through turnstile verification ？
Fair point, and very interesting! Thank you for your time.
Fair, though having headroom doesn’t mean we should take advantage of it. The more simple and minimal the protocol is, the better.
Got it, but then what use cases are there actually for ZSAs? Algorithmic stablecoins have historically had very little traction compared to non-algorithmic ones.
1 Like
I mentioned sunk cost fallacy as I didn’t hear of any tangible and actually real ZSA benefits. Non-algorithmic stablecoins are a no go from what you said, and algorithmic ones have very little traction generally, even on non-privacy smart-contract chains.
What are the actual use cases here? I disagree with the “build it and we will talk about use cases later” stance. The Zcash community has already spent millions of dollars on this, the least we can ask for is a tangible set of use cases.
1 Like
I concur with all of the above. Zcash PmF is sovereign internet native money - with privacy. This is why “Encrypted Bitcoin” worked as a message.
The attack surface being as small as possible (simplicity is the father of security) - with fair 8 year PoW distribution makes Zcash the logical successor to Bitcoin. Muddying this up either on a technology or a messaging level will throw us into a pond of tokens with no value.
1 Like
Its not that the “Encrypted Bitcoin” crowd are against upgrades. They’re against upgrades that are not in alignment with “Unstoppable Private Money. (UPM)” My view is if any upgrade damages that USP it should be discarded at the philosophical level; there is no need to continue development further or do workshops to convince people otherwise (with Crosslink). I think Tachyon is aligned with UPM.
The main issue I have with ZSAs is, I believe them to be a soft approval of Crosslink. That is to say, if we do ZSAs we may as well do Crosslink. Maybe this is not the correct way to think about it, but I am 10 times more against Crosslink than I am against ZSAs. I just imagine there will be calls for more features and better programmability once they’re introduced so in that regard they are “linked” to some extent.
1 Like
I remember using SAI in the makerDAO system back in 2016. I thought this is amazing. They eventually disbanded it and moved to DAI though, which technically isn’t freezable, but is majorly backed by freezable assets.
I then remember using RAI in the Reflexer system in 2020/2021 and trying to outlast Vitalik who held a RAI short for nearly 2 years. That failed too.
Now I think we have GHO (from Aave) and crvUSD (from Curve) whose marketcaps don’t even make 1 billion. We have largely went backwards as an industry since SAI in 2016 when it comes to decentralised stablecoins. That’s a 10 year period we are talking about where the industry has failed to deliver. So if the assets that go into ZSAs can’t be permissioned we are talking about a very small decentralised stablecoin market to compliment ZSAs.
2 Likes
@daira Thanks for the clarification on v6 transactions, that’s useful context.
To be clear, I already acknowledged earlier that “0 privacy” was imprecise. My refined concern is about practical privacy at low adoption: if issuance and burn events are distinguishable (even if z-z transfers aren’t), then a single mint followed later by a single redemption creates a strong probabilistic link regardless of intervening transaction volume.
Does v6 indistinguishability extend to issuance/burn, or only to transfers?
1 Like
At this point I’m going to apologize to you all for being intense, but somehow I really want to understand. @maxdesalle my thinking was similar to yours before I saw that JAM suggestion, now I’m questioning that thinking.
Also not one to want to bother you @ebfull in your critical work, but maybe just tell me, is that suggestion a dead-end?
How on earth do you come to that conclusion? If you have a principled argument against protocol complexity, just apply it to both features (or their combination) rather than implying that one entails the other. There is no particular dependency between them, and it’s entirely possible one will be deployed without the other.
2 Likes
I’ve said it: “I just imagine there will be calls for more features and better programmability once they’re introduced so in that regard they are “linked” to some extent.” So for example, if people want to create the decentralised stablecoin natively on Zcash using Zcash as collateral it’s going to need programmability upgrades.
Programmability upgrades don’t depend on Crosslink, or vice versa. They are likely to depend on Ragu which will be deployed as part of Tachyon.
Crosslink is an L0 upgrade; Tachyon and ZSAs are L1. There’s a very indirect link, I suppose, in that once you’ve done Crosslink, the next logical step to improve L0 latency is to reduce the block time. That is complementary to Tachyon (and also somewhat depends on Tachyon’s proof aggregation so that validators are able to keep up). I assume you don’t object to reducing L0 latency per se?
3 Likes