A specific issue with (effectively) a new class of transactions using STARKs that are not doing L1 Zcash payments, is that they can potentially crowd out non-STARK transactions. I think I would want to limit the total size (or logical actions which probably amounts to the same thing) of transactions using this TZE to a fixed maximum proportion of a block, say 1/4 or so.
3 Likes
Hey @str4d, thanks for pointers.
BTW, do you know of a trivial, end-to-end TZE example I can run locally as a platform to jump-start experiments?
4 Likes
Most of the code in the zcash_extensions crate is a demo TZE:
1 Like
Yeah thanks for the clarification sir, indeed it was not accurate. In fact we are indeed using those existing pieces of code for our proof of concept implementation.
2 Likes
yes this is a very good point.
i think it would make sense to limit them on the consensus level with a maximum proportion as you suggested or fixed number of transactions containing STARK transactions.
2 Likes
Hey, thanks for the feedback. Indeed proof size is a challenge. However, there are many possible options and mitigations we can explore, for example:
- Apply proof compression techniques:
- Select parameters that prioritize proof size over proving speed
- Implement a “shrinking” pipeline where larger STARK proofs are recursively verified in a narrow Plonkish circuit (should give proof size in range 50-100KB)
- Logical split of proof verification across multiple transactions:
- Leverage rich TZE introspection capabilities to implement covenants (and state carry)
- Split STARK verification into logical parts (not necessarily even), e.g. DEEP query decommitment, FRI decommitments, etc (should allow to split into 20-30 transactions)
- Binary split of the proof across multiple transactions:
- Split proof into chunks of the same size (arbitrary number)
- Accumulate the entire proof, then verify at once (in the final transaction)
- Requires more complex TZE context implementation and ad-hoc pricing for the verification mode
2 Likes
More colours about this question.
Pros:
- Native ZEC on Starknet, spot trading, using as collateral/cross-chain collateral (via intents or zk/storage proofs)
Cons:
- Multi-settlement mechanism is very complex and for now more of a theoretical construction
A Zcash-aligned L2 - no token, Zcash wallets support, exclusive settlement on Zcash - would probably make more sense and would bring more value to the ecosystem.
2 Likes
A generalized STARK TZE can indeed be used to construct a bi-directional trust-minimized bridge between Zcash and Ethereum (and potentially other smart contract chains).
Assuming that at some point Zcash adds support for multiple assets to the shielded pool (requires a more complex circuit) it would allow things like shielded ETH. The benefit compared to Ethereum-native privacy pools is the size of the anonymity set.
1 Like
but Crosslink would certainly improve Starknet UX:
- Reduced processing time for deposits and withdrawals (to and from L2)
- More straightforward bridge integrations for Ztarknet (similar to the Ethereum L2 workflows)
4 Likes
Starknet-based chains have a dual model (similar to Zcash that supports both transparent and shielded transfers) with application-specific privacy (meaning that no specific privacy solution is enshrined at the protocol level, yet).
So the answer is yes, eventually, but that’s a parallel effort given that it does not depend on the chain itself. There are already several privacy primitives available for builders:
- Privacy pools — Zcash-like construction with a mechanism preventing your association with illicit funds (e.g. from a hack or ransom)
- Confidential tokens — enables semi-shielded transfers (hides balances and amounts), similar to the solution deployed on Liquid (Bitcoin sidechain)
There are several other efforts to enable Railgun-style private gateway to DeFi as well as shielded DeFi primitives. Starknet stack provides cost-efficient and developer friendly toolset for building privacy applications using Noir language and Aztec proving system.
1 Like
Out of curiosity what tradeoffs do we have to take to get the recursive size to sub 64kb?
Can we maintain 128 bit soundness? My guess would be its something like:
- Small initial rate (<= 1/8)
- STIR instead of FRI
- 2^24 proof of work to reduce number of queries
- (Arithmetize to keep the number of registers very small)
I’m assuming we’d be taking the RS proximity gap conjecture, with some margin of error? (To account for all the recent paper’s progress)
1 Like
In order to handle user force withdraws, it seems like it would be problematic to require every user to independently post a full ZKP proof. Do we need to plan for force withdraws potentially taking a long time (50kb / user withdrawing), or should we imagine the L1 “caching” ZKP’d headers, and then its just a light client proof per force withdraw?
1 Like
Forced withdrawals as a part of censorship resistance feature require either:
- an escape hatch - which will allow to exit the bridge in case sequencer ignores the forced withdrawal
- a permissionless block building - if the sequencer is ignoring the forced withdrawal request, interested party is able to execute and prove the withdrawal itself
Escape hatches do not go well with general purpose composable smart contract rollups because it requires L2 state which is defined by arbitrary smart contracts to be interpreted by a relatively static L1 escape hatch handler. They work well only for application specific rollups where L2 state is well defined.
This leaves us with permissionless block building which indeed is resource intensive. The good thing is that many withdrawals can be aggregated into a single state update which eliminates problems with mass exit on L1.
3 Likes
A narrow recursive verification circuit will probably be the main driver, giving an order of magnitude reduction in proof size. This is what we are actively working on right now.
Longer term we might switch to WHIR, but there are some changes to the multi-domain commitment scheme that are necessary to be done first (see Lifted FRI). Also STIR/WHIR do not provide significant improvement for a wide trace, so it would only make sense to apply to the narrow verification circuit.
Regarding the code rate: we are currently at ½ and but can go down to ¼ and further depending on the recursive verification trace size (since we are bounded by the LDE domain, and it would also be nice to stay within manageable RAM limits at the commitment step).
Currently we do 26 bits of work (that adds negligible overhead timewise), and can go up to ~32 bits (that would take around 10mins on a large machine).
Generally we rely on the toy problem conjecture when choosing parameters, the latest updates on the bounds are in this paper https://eccc.weizmann.ac.il/report/2025/169/
And another reply from Eli Ben Sasson that I am quoting here is:
STIR vs FRI doesn't matter in the way we do things. Explanation: We use a very wide trace, and the first iteration, which is the same whether you do STIR of FRI, is the same. The rest of the protocol is, like 1% compared to that first step. So not worth the extra complexity to move from STIR to FRI.
4 Likes
Hypothetically speaking, is the ztarknet repo ready for local usage as an L2 (to deploy PoC contracts on it and invoke them)?
Am currently trying to sandbox some stuff and am running into invalid signature errors using the pre-funded accounts.
I’m assuming this is just a skill issue rn, but im curious if you could let me know if this is a dead-end (not ready yet), or if i just have my tooling set to the wrong versions (i.e starknet-foundry & starkli)
1 Like
Yes, you can already experiment with it! It differs from devnet/sepolia in some settings, but most of the tooling should work out of the box. I recommend starting with GitHub - Ztarknet/quickstart: Tutorial: deploy privacy preserving application on Ztarknet
Agree Cairo and STwo / Stone are good choices for a programmability layer on ZCash, however I am concerned about fragmenting users’ ZEC holdings in a different domain as the shielded pool on L1.
If for example, there is DeFi on Ztarknet, users might be inclined to bridge ZEC up to Ztarknet and hold and transact up there, instead of holding and transacting in the shielded pool. If ZEC is not actively locked in DeFi, then it should be shielded in the best possible place, alongside as much other ZEC as possible.
There are a few ways we could deal with this, assuming we abstract the bridge away from the user:
- If Cairo has an equivallent to payable transactions, we can bundle an unshield transaction with a bridge transaction and a deposit transaction, for arbitrary smart contracts.
- We could do the reverse when withdrawing ZEC from smart contracts: detect if any Ztarknet transaction outputs +ZEC, and automatically bundle that with a bridge transaction back to L1, and a shield transaction.
- Cairo and Stwo could be enshrined in the L1 instead of building L2s
6 Likes
Thank you for the feedback! Agree that long-term hold function belongs to L1 while L2s are for trading, payments, gaming etc. Actually if we think of Ztarknet as a stack for appchains rather than a generic L2 it starts to make much more sense. One of the use cases we had in mind while drafting the proposal was a shielded (prividium-level privacy) perp DEX, like Paradex.
In that case your scheme is a great fit: we can do bundled deposits/withdrawals via custom integration with Paradex contracts. If we were to handle a generic scenario it would be much harder (not sure if possible at all).
Wrt enshrining an alternative runtime in the L1: I don’t think Cairo is a good fit and it wasn’t designed for this. Imo something like Simplicity would be a better replacement for Bitcoin script 
Maybe once Tachyon introduces recursive proofs one can build conditional shielded transfers and we will have programmable privacy 