Ztarknet native token is to be ZEC, there are no plans to introduce a separate fee/governance token.
Given the progressive decentralization in the roadmap it would also be quite hard to bootstrap a new tokenomics from scratch. Assuming that Crosslink hits mainnet at some point, it would be much easier to piggyback on the existing staking mechanism.
In that sense Ztarknet is a native/enshrined rollup (fully aligned with the settlement layer).
Also BTW I work at routescan, we’d love to explorer if we can make a unified explorer for zcash + ztarknet eventually.
AMAZING, let’s collaborate yeah
Would you like to expand on this?
depending on implementation but on an L2 liek this you would not need to trust any validator network regarding “valid” state transition function on the L2. So you cant just move ZEC you dont have on the L2 and withdraw back to Zcash l1.
Echoing what @JoakimEQ said here
Assuming the L2 works similarly to other L2s in Ethereum / Bitcoin, the block proposer / prover cannot collude and produce an invalid state transition to drain the bridge.
All L2 full nodes execute proposed transactions and collectively agree on the latest state root. For the bridges view of the state to be updated, a validity proof referencing the latest, valid state root is needed. To produce the proof, the valid state root is needed as one of the inputs. Proof generation fails without it, thus the prover (the node who publishes proofs to the verifier on Zcash) cannot cheat and produce an “invalid” proof per se.
This is different to a sidechain/PoS bridge network as the verifier on Zcash would follow the fork with the greatest amount of hash rate / stake weight, so a malicious private fork with sufficient economic weight behind it could submit an invalid state root, “trick” the verifier, and drain the associated bridge.
And of course, multisigs holding ZEC, that backs wZEC on other chains, can just have dishonest majority steal all the money.
exactly yes
yes exactly, thanks a lot for taking the time to add clarifications and explanations, truly appreciate your help here
I wouldn’t say it’s generally expensive, because there’s very little transaction volume on the L1, it’s not like ethereum. Also, there’s no fee market, so the only change that makes sense for Ztarknet to be more suitable / cheaper is to change transaction fees at protocol level, and I believe that is what needed nevertheless because of ZEC’s recent repreciation.
As for everything else, it does make sense, thank your for clarifying!
DM’ing you on X!
hey @daira thanks for the feedback, really appreciate as usual.
I wrote more elements on those things as well as blockspace footprint, security etc.
In my opinion, there are both PROS and CONS:
PROS - An L2 would enable:
• ZEC as the native fee token
• Minting tokens and NFTs
• Using these tokens in DeFi applications
• Bridging ZEC for DeFi (I’ve wanted a ZEC-collateralized stablecoin for years)
• Attracting developers to the Zcash ecosystem (though this requires grant funding)
CONS - My concerns:
• Without private DeFi, this L2 doesn’t offer a compelling advantage. Existing solutions like Ethereum L2s or Solana (which already has bridged ZEC) would serve the same purpose.
• This adds protocol complexity to Zcash L1, potentially complicating the Tachyon implementation (though I’m not technical enough to fully assess this).
• Programmability and shielded assets are already on Zcash’s roadmap, making an L2 potentially redundant.
Bottom line: Without private smart contracts, I don’t see a strong use case for a Zcash-specific L2.
Thanks for your feedback. I will address some elements.
You are right on all the PROS. But there are more:
Now let’s address the CONS.
Without private DeFi, this L2 doesn’t offer a compelling advantage. Existing solutions like Ethereum L2s or Solana (which already has bridged ZEC) would serve the same purpose.
a) nothing prevent having a private L2 using the same model, in fact when Starknet has privacy on the protocol layer (and we are working on it), it would work with the same mechanism b) even without privacy on the L2 you still have some advantages in comparison to Ethereum L2s or Solana with bridged ZEC: it’s not the same at all in terms of trust assumptions, a ZEC asset bridged to a Zcash L2 is much better in terms of security and inherit most of the properties of the base layer unlike those solutions
• This adds protocol complexity to Zcash L1, potentially complicating the Tachyon implementation (though I’m not technical enough to fully assess this).
Quite the contrary to be honest. One of the main advantage of L2s is the fact that they enable to offload the complexity of computation and programmability from the base layer. So yes it has an initial complexity cost (somewhat reasonable to be honest) to enable them, but when you have them then you can innovate much faster on L2s and offload complexity.
Programmability and shielded assets are already on Zcash’s roadmap, making an L2 potentially redundant.
Related to the point above, i believe it’s better to bring expressivity and programmability via L2s and keep the L1 minimal and simple.
Bottom line : Without private smart contracts, I don’t see a strong use case for a Zcash-specific L2.
Again, you definitely can have a private L2 on top of Zcash using the same model.
Thank you for taking your time to answer, truly appreciated.
With your clarification it makes much more sense to add a ztarknet L2 and ditch programmability in L1.
The argument against centralization here is that it is a single point of failure for denial-of-service, legal attacks, or unavailability due to technical failure on the L2.
Thanks for walking me through this.
true but it does not have to be centralised sequencers. In fact Starknet today supports decentralisation of sequencers using a BFT consensus. Also, it could totally be permissionless block building and proving. can be also proof of work. it’s orthogonal to the security mechanism of the ZK rollup itself
@januszgrze Not to detract from the proposal, but this is an implementation detail.. an L2 can have a multisig that could instantly steal all money in the bridge as well (and many L2s on Ethereum do have one).
@abdel I am wondering why you chose a STARK-specific TZE vs a collection of opcodes that would enable building various flavors of validity rollups? For example, we could instead add recursive covenant, merkle path verification, and prime field arithmetic opcodes. This would enable building verifiers in Script for Circle-STARKs, Halo2, and other popular proving systems. Then the L2 designer can have more options to decide what proving system to use. Personally I prefer this approach vs a STARK-specific TZE like what is proposed here.
I am wondering why you chose a STARK-specific TZE vs a collection of opcodes that would enable building various flavors of validity rollups? For example, we could instead add recursive covenant, merkle path verification, and prime field arithmetic opcodes. This would enable building verifiers in Script for Circle-STARKs, Halo2, and other popular proving systems. Then the L2 designer can have more options to decide what proving system to use. Personally I prefer this approach vs a STARK-specific TZE like what is proposed here.
Yes i understand your concern. The thing is that i STRONGLY believe that the TZE path is much better than opcodes. Bitcoin Script is a nightmare, complex, error prone, hard to audit and to make secure etc.
Maybe it could be done with multiple TZEs providing each the primitives you mentioned, but not sure about how to combine them properly and the inherent complexity
Can add that even re-enabling existing opcodes in Bitcoin script is quite problematic - need to analyze potential security implications (specifically dos vector), provide compelling use cases (ideally multiple) for each opcode or specific combination of opcodes, implement custom pricing if necessary (e.g. see varops in btc).
We could imagine an alternative approach where instead of a TZE we have:
This should make STARK verifier feasible (although still quite expensive!) but at the cost of a huge changes in the codebase (beyond just script interpreter). And that’s for already implemented, tested, and carefully analysed opcodes. For new ones it would take significantly more time and efforts.
I do agree that TZEs are very case specific and it’s hard to make them generic without some “glue“ around. Maybe there’s a path to interoperability between scripts and TZEs that would solve that problem.
Personally, I would be in favour of an alternative execution runtime like Simplicity, which addresses the issues of Bitcoin script and provides a clear workflow for optimising particular operations.
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)