I have been hoping for movement in this direction for nearly four years, so this is really exciting to hear! Zcash <-> Cosmos Integration
Although I’m now on the sidelines of the Zcash effort, I would implore the Zcash community to choose Tendermint/CometBFT off-the-shelf as the PoS implementation, rather than putting effort into building or customizing it in any way. It is written in Go, but there is no problem interacting with it from other languages like Rust using ABCI.
This approach has two enormous advantages:
- Light Client Compatibility: using CometBFT off the shelf means that the state of the PoS subprotocol can be verified using an off-the-shelf light client, and importantly, it can be verified on-chain by every Cosmos chain. This opens the door to IBC connections to Zcash.
- No custom engineering: using CometBFT off the shelf means that Zcash can skip the engineering effort of designing and building a new consensus mechanism, and can reuse the investment made by the entire Cosmos ecosystem.
At this point there’s no problem with using CometBFT to drive the state of a Rust application (and have that Rust application implement custom staking logic). We do so for Penumbra; you could look at our source code as an example and potentially also reuse our stack. For instance, Namada uses our tower-abci library for interfacing with CometBFT and Astria uses penumbra-storage for state management, penumbra-component for application structuring, and penumbra-ibc for an IBC implementation.
If the Zcash TFL design pulled CometBFT off-the-shelf, it could potentially go the Astria route, reuse parts of the Penumbra stack, and have a drop-in IBC implementation for Zcash on a very accelerated timeline (completion within your medium term roadmap). We’d love for the Zcash community to be able to take advantage of the code we’ve written and we’d be happy to answer questions about it.