Started looking into this a bit based on this post. It seems possible that CKB could verify ZCash proof of work. ZCash uses Blake2b for hash function, we need 512 hashes to verify a header. Blake2b is roughly 20,000 cycles, so this is a reasonable number.
ZCash implements FlyClient, so with 1 header verification we could have certainty around chain history (would require verifying the FlyClient sampled headers as well)
Thanks for creating this.
As confirmed, RGB++ is off the table for native ZEC — so direct Zcash integration on Rosen Bridge is the path worth exploring.
I appreciate you digging into this, the FlyClient point is interesting. To confirm my understanding: this means CKB could trustlessly verify that a ZEC transaction actually happened on the Zcash chain, which would be the foundation for any kind of Zcash integration whether that’s Rosen Bridge or otherwise?
Seems like theoretically yes CKB could verify a Zcash transaction was included in the chain. As far as foundation for Rosen Bridge.. seems like a different topic at hand, Rosen integration would be it’s own implementation separate from this.
So from my understanding, Rosen Bridge uses a Guard-controlled multisig on the source chain federated custody, more secure than a single custodian but not truly trustless.
Separately, the FlyClient/CKB verification capability you’ve identified opens a theoretically trustless path where ZEC locked on Zcash’s own chain, verified by CKB. Would that be correct?
Yes, however that ZEC is not “wrapped”– its sitting in an address that is controlled by someone. Nothing on CKB can prevent that ZEC from moving.
In a bridge example, the signers control the ZEC.
RGB++ is useful for trading a native asset for a user-generated asset, like Stable++ or a Nervape in exchange for BTC, but it doesn’t work for Defi things on another chain, which you would need a wrapped asset for.
————————————
There may be some sort of derivative agreements that make things closer to Defi possible in the RGB++ kind of paradigm but no one has taken up this research task.
MVB ( Minimum Viable Borrowing (MVB) on CKB ) and Warranty Contract ( [V0 Looking for feedback] Warranty Contract, a next-gen DeFi Primitive ) are the seeds of this kind of thing but there is a lot more work to do to figure out how a financial system can be constructed with these kind of primitives (which would be some action that is conditionally enforced if say the ZEC moves on ZCash before a certain date).
Thanks again Matt. I’ll discuss with the Cyfrin team who are building this and come back if there’s appetite to take this further.
@matt_ckb Thinking more of this if Zcash were integrated directly on Rosen Bridge, would that provide sufficient proof of reserve without needing CKB as an intermediary?
I think so
@BuildUnion RGB++ idea you proposed is not viable (feel free to double check with @fgh about RGB++ idea). Conversely, making Rosen Bridge integration on ZCash should be doable, see requirements: rcs/rcs-003 at master · rosen-bridge/rcs · GitHub
Good luck and happy building, Phroi
