Here’s a list of chain upgrade proposals I think we should land in NU8, and target it for late January!
Release of the Tachyon shielded pool
An extensible TX format to avoid adding extra distinguishability to unupgraded HW wallets with every new shielded pool.
Raise max block size from 2MB to 8MB
Add post-quantum transparent opcodes, to add 128 bit and 192 bit secure SPHINCs variants
In-protocol move the NSM redistribution date to around Zcash’s 7th halvening
In protocol finalization of a date for Sapling to remove deposits. (Transactions and withdraws still enabled)
Removal of “consensus branch ID” updates, to cease breaking wallets every NU
On raising the max block size, we currently have this ZIP open for an increase to 3MB: Draft ZIP: Increase the block size limit to 3 MB by evan-forbes · Pull Request #1448 · zcash/zips · GitHub . Our belief is that this, and 4MB, are already safe for deployment on the network at 20s blocks, and was originally written with an expedited NU7.1 in mind. With the ongoing work in both Zakura and Zebra-Andele, we actually think 8MB is a reasonable proposal for a late January upgrade, and plan propose 8MB or higher depending on implementation status at NU8 polling time.
On PQ Transparent opcodes using SPHINCs, Valargroup plans to put a ZIP up soon and begin the necessary discussion for it.
If combined, this sets up extremely well for many of the concurrent goals going on.
Scale is enabled with both Tachyon and bigger blocks. Composed together that would achieve 200 shielded TPS!
Post-Quantum:
Unconditional Post-quantum Privacy is live with Tachyon (ML-KEM ciphertexts)
PQ Transparent gives a live solution today for where Ironwood recovery can go into
Sapling users have a clear in-protocol signal to begin moving, with the necessary time to adapt.
The NSM can plausibly delay the tail emissions problem by 1-2 extra halvenings
Software wallets and hardware wallets stop breaking every NU
2.5 months is not much time, and I haven’t seen any updates from Project Tachyon in the ZIPs repo proposing either ZIPs or updates to the Zcash Protocol Spec. The Tachyon Roadmap says “Once community consensus is reached and the proposal meets Zcash’s ZIP requirements, we will activate on mainnet” - how close is Tachyon to the latter?
I agree, we should get ZIP 248 deployed ASAP. Its design has been stable for well over half a year, and I’ve been cleaning the ZIP itself up over the past week (mainly updating it to take into account other consensus changes that have been deployed in the interim).
Your rationale both here and in the linked ZIP draft solely focus on the impact on full nodes. The ZIP draft alludes to in future using OOB / PIR for wallets, but given that there are still no specifications for either of these, and thus I expect most wallets won’t have deployed solutions for this within 2 months, any proposal to raise the block size will need to analyse the impact on as-deployed wallets using the light client protocol.
Any proposal to remove this needs to also propose a replacement mechanism for preventing transaction replays across forks. That was the original rationale for including this mechanism in ZIP 200, as replay protection was a hard requirement by various cryptocurrency ecosystem players at the time. It would also be nice for any replacement mechanism to also handle malicious forks (i.e. a fork solely intended on disrupting the main Zcash chain, rather than the friendly forks we designed ZIP 200 to enable and protect Zcash users against).
I noted elsewhere that once ZIP 248 is active, it will be pretty easy to define a sighash variant that doesn’t commit to the consensus branch ID (and other fields that prevent pre-authorization, which seems to be the main issue I’ve heard about), which users who are willing to lose replay protection could opt into.