Quick update on the last ~48 hours of Zcash Ironwood!
1. Protocol devs from across all the orgs met twice to discuss specification and implementation progress. Agreement on a couple additional changes: disabling Orchard pool bundles in coinbases, anchors as auth data for migration UX with hardware wallets, and the order that ZIPs and specs will be handled.
2. Ironwood circuit and ZIP 2005 integration drafts are going through the review process.
@ValarGroup has already spun up testnets and his team has done a wonderful job scoping out and implementing some of the wallet-facing changes. We are beginning an Ironwood upgrade book for eventual consumption by auditors, wallets, protocol developers, etc..
3. Formal verification work on Ironwood continues. A collection of different individuals who either have or will continue to work on formalization efforts will be meeting tomorrow where we'll settle on the specific strategy for getting the Ironwood SNARK formally verified. I'm hosting this and will post minutes and details after. Efforts from teams will be ideally combined where useful, existing approaches and progress unified and we'll figure out the easiest path for the next couple weeks. I've paused my own work on this to do Ironwood circuit stuff, but I'll be resuming on that tomorrow.
These are the big pieces, there are also some major security auditing tasks taking place in the background -- at least three major firms are auditing Orchard currently, and multiple new AI auditing suites are hammering the codebases to ensure nothing else critical is sitting around anywhere. So far so good!
Really proud of how much progress is being made every hour on this by all five of our major teams/orgs and our supporters inside and outside the community. Also love the general wartime vibe shift. Let's go!
UPDATE: The various orgs and protocol developers mentioned have agreed on the specific consensus rule changes for Ironwood, after settling the finer details.
Here's a summary:
1. Ironwood introduces a new pool using the Orchard protocol, just like the existing pool.
2. The circuit for the Orchard protocol—which applies to both the existing Orchard pool and the new Ironwood pool—will have a flag that consensus rules can toggle. This flag disables payments to *other* users within that pool, while maintaining the ability to create change notes. (This enables a privacy safeguard.)
3. The old Orchard pool will have this flag enabled after the network upgrade, and payments to the old pool will also be disabled by constraining valueBalance.
4. Because payments are disabled on the old pool, wallets must send new payments to Orchard receivers (inside existing unified addresses) via the new pool, and they should also migrate funds away from the old pool.
This combination enforces a bound on the circulating supply of ZEC through the use of the existing turnstile mechanism; the amount of ZEC that anyone can transact with is no more than the amount that is supposed to exist. Meanwhile, users' wallets can migrate funds to protect them from risk, which also gradually provides evidence that counterfeiting never took place.
Now that we have this decided, we'll collectively move on to the implementations, specifications, and ecosystem support/outreach. (We also have many different auditing and formal verification efforts taking place behind the scenes to provide assurance about the circuit correctness. More on that soon!)