Our first Zcash Aborist Call will be July 2nd at 21:30 UTC!
Registration is now open and you can sign up for the call here.
Arborist calls are monthly calls where Zcash protocol contributors convene to discuss upgrade timelines and process, protocol R&D efforts, design and implementation of new protocol features, and identify blockers and unresolved issues. See this post for full details.
This week we’ll have two detailed presentations. Henry de Valence will present on the Zcash Cosmos Pegzone design and I’ll be presenting proposed changes to the Network Upgrade Pipeline.
If you’re interested in presenting at future Arborist calls, contact me at steven@electriccoin.co with “Arborist Call” in the subject line.
2 Likes
Meeting notes - taken by me. If you see any corrections or improvements, please let me know! Many times I paraphrased and may have missed important details or misheard.
Consensus Node updates:
Zebrad - Deirdre
- Two new hires: Jane and Teor, team velocity is taking off!
- Async verification framework for signatures, proofs, transactions, and chainstate that can take advantage of batching.
- Network stack is largely done.
- All of the components are separate modular libraries (about 5 of them).
- Aiming to get mainnet validation by NU3 activation - sounds like prototype/proof of concept and/or alpha. It’s pretty close.
Zebra Q&A:
Q. Impressed with how much has been accomplished recently. How is Zebra verifying Sapling proofs? Is it calling into ECC rust code?
- Yes. First pass for Zebra delegates to Bellman for Sapling-groth verification. It presents many as a batch.
- For redjubjub they implemented some optimizations. They want to do similar in the future for Groth16, but probably not in the first release. They also want to push that upstream when they can.
Q. Where are the verification keys? Are they baked into the code?
- A contributor split them into multiple crates as a hack to fit them into Cargo dependencies, but they probably won’t use that for the time being.
- The first release may ship some of the param data next to the source.
- First release only verifies chain, no wallet, no txn generation.
Q. What set of consensus rules will be supported? Only Sapling?
- We will checkpoint on Sapling activation.
- The implementation is split among crates modularly. Are there other tools/projects using the separate pieces?
- The Zcash Foundation seeder uses a version of zebra, rather than a subset of libraries.
- People have shown interest in building atop zebra-network.
Q. What kind of provisions are being made in zebrad for network layer privacy? Even if they are not going to be implemented by the NU3 release
- We’re working on a network privacy threat model document (Primarily Chelsea Komlo has been doing that work) - we will have a draft in a week or two.
- The design of our network layer makes it substantially easier to integrate network changes
zcashd - Steven
- Focused on 3.1.0 release.
- Working on audits for NU4 Canopy.
- Specification Audit from NCC group, no significant findings.
Presentations
Cosmos Pegzone Design - Henry
Reference: zcash-pegzone/README.md at main · ZcashFoundation/zcash-pegzone · GitHub
- It starts with motivation for two audiences: Zcash fans and Cosmos fans.
- Zcash privacy network effects may be stronger than typical privacy tools since all prior transactions contribute to the anonymity set.
- Roadmap split into Two Phases.
Phase One
- Pegged ZEC, PZEC, and staking mechanics which will be compatible with a future upgrade which enables shielding across the Pegzone. This phase will not have on-chain privacy.
- Users can send from a Z-addr on Zcash chain to validators who then issue PZEC into the Cosmos zone.
- Users can send PZEC in the Cosmos zone back towards the Zcash chain with a specific transaction type which validators honor by sending ZEC on the Zcash chain.
Phase two
- Upgrade the Cosmos pegzone to use Sapling-style privacy across the entire zone. - This phase may also add multi-asset support where the Zone can support any number of Cosmos assets all of which share a common shielded privacy pool.
- In Phase 2 Zcash network has a Sapling pool, and the Pegzone has its own pool.
- When transferring between them, what information is revealed?
- This part is more of an open question, because phase 2 is further afield. Worst case: amount of every bridging is revealed. It may also be possible to do something better.
- What if you had a commitment tree that was split between two halves…
- The issue that comes to mind is that if the total amount of the pegged supply is public, there’s a limit on what privacy we can get because you could watch changes per block.
- Even in the worst case which reveals every transaction amount is similar to a Zcash turnstile, and that’s quite a lot of privacy compared to a t->z setting because if you split amounts to random amounts, you have less info than a t-addr case where you can do downstream chain analysis [note-taker: paraphrase/guess?].
Q. Do validators have information about transfers across the bridge that the public does not have? We should track that carefully.
- Validator behavior needs to be publicly verifiable to some degree so this may not be an issue. [In other words the set of information they see would be close to what the public can deduce anyway?]
Phase 1 Mechanism Design:
- We want the design to have good incentives for staking that will still be able to function in Phase 2 with shielding.
- There are two units DZEC vs SZEC, and converting between them uses a known global exchange rate that depreciates at an exponential rate. Converting between them doesn’t require any account-specific tracking and can use a local stateless multiplication. This is completely compatible with storing these assets in a shielded pool without needing per-account state updates over time.
- Contrast this to, eg Cosmos atom staking, where accounts and delegations are tracked explicitly and publicly.
Q. How do DZEC/SZEC relate to PZEC?
- The Zcash network ZEC backing PZEC lives at a validator z-addr on Zcash network.
- Validators use a PoS consensus, SZEC is one-way convertible from ZEC-on-Zcash, ie: on Zcash you can do a publicly visible one-way transfer of ZEC-on-Zcash which the Zone rules honor by issuing SZEC.
Q. Is the total delegated staking ZEC for each validator visible?
Q. Why not provide Sapling SDK to all of Cosmos?
- If each Zone implements privacy separately, their privacy pools will be fragmented.
- If Cosmos tokens all migrate into a common pool, they all reinforce the same network effect.
Fee mechanics:
- The cost to keep funds across the peg is proportional to the amount integrated over time, then the same exchange rate mechanism is used, so that there’s no need to do per-account tracking of PZEC, which is also compatible with Phase 2 shielding.
Q. Why burn ZEC to obtain SZEC/DZEC? There’s no way to redeem it?
- We need to create a new staking token, and we don’t want to centrally control the issuance, so this seems like a relatively simple way to do this with decentralization.
Q. What about a conversion of PZEC → SZEC?
- It’s basically equivalent to ZEC → SZEC
Q. Does PZEC → SZEC really help control the staking supply?
- [Note-taker missed the answer, but there was some mention of a cap on the amount of PZEC based on SZEC size?]
Q. [Note-taker missed this a bit] something about unifying the privacy set across both chains.
- [Note-taker missed answers]
Key derivation capabilities
Validators will share the spend authorization key using FROST (designed by Chelsea Kohmlo & Ian Goldberg, see FROST tech report) and Viewing Keys will be replicated, and that can be used as part of a slashing implementation. This presents a slight complication compared to Cosmos Hub - in CH validators can change every block. In Zcash Pegzone validator set will only change at particular epochs as a normal mode of behavior (rather than exceptional) and make it frequent enough to be difficult to ignore.
Other Announcements / Misc Discussion
A couple of clarifications about IBC:
- The “transfer” protocol is just one App protocol on IBC. You can define others.
- Also, we enhanced IBC so that it can support PoW chains that do not have fast finality. It does require more scripting power than Zcash currently has, so a peg zone is still required for ZEC
5 Likes