I had a nice chat with the fine folks working on FROST at Zcon3 today and thought I’d put down a few thoughts on a potential Zcash <> Namada / IBC ecosystem / Ethereum ecosystem bridge while they were top-of-mind.
Quick summary:
Heliax is interested in building a non-custodial bridge between Zcash and the IBC & Ethereum ecosystems as part of our Namada blockchain. Namada is a sovereign, proof-of-stake, Tendermint-based blockchain with various features (see specs), but the proposed architecture here is general and could potentially be implemented by other Tendermint-based chains, and users of the bridge need not concern themselves with other Namada features and need not possess the Namada proof-of-stake native asset in order to use the bridge. Using this bridge, users of Zcash would be able to send their ZEC to and from Namada, IBC-compatible blockchains, and Ethereum without additional trust assumptions besides the regular BFT ones (2/3 correct) of the Namada validator set. If the Zcash community decides to support ZSAs in the future, users would also be able to send other assets to the Zcash blockchain and transact privately with those assets on Zcash (then potentially bridge them back in the future). This bridge relies on the FROST threshold multisignature scheme currently in final stages of specification and development, and it provides some privacy but not the same privacy as z2z transfers on Zcash. We’d like to get feedback from the Zcash community on the proposed bridge architecture and gauge the general level of interest in using such a bridge.
Bridge architecture
The basic element of this bridge architecture are:
- A threshold multisignature account on the Zcash chain operated by the Namada validator set at the same voting weights and threshold as Namada’s Tendermint BFT consensus (so 2/3 of ~ 100s to 1000s of shares depending on the proof-of-stake voting weight approximation accuracy), created and operated using the FROST multisignature scheme currently nearing standardisation
- An alteration to the Namada consensus rules requiring Namada validators to run Zcash full nodes and to operate a Zcash consensus oracle, such that once 2/3 of Namada validators have seen a particular Zcash block (or transaction included in that block) with a certain confirmation depth, this can be registered on the Namada chain (but not before 2/3 of validators have seen it at the required confirmation depth)
- An IBC/ICS20-style (ref) asset bridging mechanic implemented by the Namada chain’s state machine to create and track asset vouchers
Bridge transactions would then work as follows:
Sending from Zcash to Namada / other chains:
- The user creates a transaction sending however many ZEC (or another asset) they would like to bridge to the z-address generated from the FROST threshold multisignature key. They include in the memo field a recipient address and block confirmation depth (and potentially forwarding information, though this may be limited by size constraints).
- The validators of Namada, after waiting the block confirmation depth indicated by the user, vote on the Namada chain to indicate that they have seen the transaction to the multisignature (agreeing on its contents & validity).
- After 2/3 (by stake) confirmations on the Namada chain, the Namada chain mints ZEC (or other asset) vouchers on Namada in exact correspondence to the amount of ZEC (or other asset) sent to the multisignature and sends them to the destination indicated in the memo field (which may be on another chain over an IBC channel or the Ethereum bridge).
- These ZEC (or other asset) vouchers can then be used normally as a fungible asset on Namada, other IBC-compatible chains, or Ethereum.
Sending from Namada / other chains to Zcash:
- A user with ZEC (or other asset originating on the Zcash chain) vouchers, who may have sent them from Zcash originally themselves or may have acquired them from another user who did, decides to send the asset back to Zcash and redeem for ZEC (or another ZSA). They send the asset to Namada, to a special bridge account, and indicate the intended destination z-address on the Zchain chain.
- The Namada chain burns the Zcash (or other asset) vouchers on Namada, and the Namada validator set runs the FROST threshold multisignature protocol over a Zcash shielded transaction to create a Schnorr signature over a Zcash transaction sending the specified amount of ZEC (or other ZSA) from the multisignature account on Zcash to the specified destination.
- The Zcash blockchain accepts, validates, and confirms the transaction (indistinguishable from any other shielded transaction), and after however many confirmations they would like to wait the user has regular ZEC (or other ZSA) in their account on Zcash.
In general, this bridge architecture makes only Namada 2/3-by-stake (BFT) security assumptions, in that valid multisignature transactions can only be generated by 2/3 of the validators and transactions from Zcash are only accepted once 2/3 of the validators have seen the transaction and run the Zcash full node logic to check that it is valid and has been confirmed with the requisite depth. By having each validator run a FROST coordinator, it should be possible to kick out any non-compliant party (so achieving liveness under 2/3 correct, though perhaps after a round of kicking some out), and it should be possible for any validator who ran a coordinator to see if any other validator signed a FROST share which they shouldn’t have. It is still possible for 2/3 of the validator set to collude in private, with someone running a private FROST coordinator, and produce a valid FROST signature which will not be fault-accountable - but 2/3 of the validator set can collude and sign arbitrary valid blocks anyways, so this is not much of an additional concern security-wise.
Namada uses epoched proof-of-stake, so to retain synchronisation with the proof-of-stake & BFT voting weights a new z-address would need to be generated every epoch (on the order of days) and assets from the previous address sent to the new one. Users will need to be careful not to send to old bridge addresses which cannot be guaranteed to be live. Some details remain to be worked out here.
Privacy properties
In this simple version of the bridge architecture, the viewing key of the bridge multisignature would be publicly known, so amounts and destinations (in the memo field) of bridge transactions would be public when sending from Zcash to/through the bridge - users can send from a z-address to the multisignature, so the sender is private, and the destination could potentially be be a one-time shielded address on Namada (or another chain) so funds could automatically be made private again immediately after bridging, meaning that effectively only the amount (and timing information) is public. When sending to Zcash, the amount and destination on Zcash (which can similarly be a z-address) must be made public so that the validators can sign using FROST, so using one-time addresses the privacy should be similar (sender/recipient private, amount & timing information public) if sending from a shielded pool, with loss of sender privacy if sending from a public account/chain.
Namada also supports a shielded pool, as do some other chains, and ideally it would be possible to bridge assets completely in private hiding amounts (and thus merging the shielded pools from a privacy perspective). However, retaining fault isolation with private bridges requires some additional cryptography due to the multi-user private state involved. We have a separate research proposal outlining a way in which this might be done, but it requires a validator set and alterations to consensus rules, so probably wouldn’t be feasible if/until Zcash switches to proof-of-stake (and even then may require substantial protocol changes). An alternative scheme not requiring any changes to Zcash may be possible for Namada validators to run privately using their threshold key shares and some kind of MPC for the viewing key and transactions to be signed (this would not achieve privacy to the Namada validators, but it would achieve privacy to external observers) and we can investigate this in more detail.
User experience
Tendermint consensus provides fast finality with a latency of a few seconds realtime, so the primary determinant of latency will be proof-of-work confirmation time (on the current Zcash blockchain, this may change if Zcash switches to proof-of-stake in the future).
Outwards (bridging from Zcash)
In order to transfer ZEC from Zcash to Namada, users of the bridge would need to wait for a configurable threshold of Zcash proof-of-work confirmations beyond which the Zcash chain is not expected to fork, which will be the main contributor to latency. For example, waiting 10 confirmations at a 75-second block time would take 12.5 minutes on average and waiting 20 would take 25 minutes. Once the confirmation threshold has passed, the ZEC transfer can be confirmed on Namada and ZEC can be bridged to other IBC-compatible chains or to Ethereum immediately (modulo their confirmation times and gas markets).
Transfers of ZEC to Namada, IBC-compatible chains, and Ethereum can pay fees in Namada denominated in ZEC, so users do not need any additional assets to use the bridge (however, paying Ethereum gas fees or other IBC-compatible chain gas fees may require those chains’ native assets).
Inwards (bridging to Zcash)
Transfers from Namada to Zcash (potentially initially originating on other IBC-compatible chains or Ethereum) should take on the order of tens of seconds from the bridge’s perspective (just a few Tendermint consensus rounds for the FROST signature generation). Users will need to wait for however many confirmations on the Zcash chain they normally would, although it’s worth noting that accepting zero-confirmation transactions is substantially safer in this case since there is additional double-spend protection provided by the bridge.
Similarly to the outgoing direction, transfers from Namada to Zcash can pay fees denominated in ZEC, so users would not need any additional assets in order to use the bridge.
Thanks for reading, questions welcome! This is just a sketch - if there is interest we’ll write up a more formal specification proposal. In particular, some details around epoch changes and ZKP creation for the transactions from the multisig need to be worked out, and I have made some guesses on how FROST multisignatures would work with viewing keys which might be wrong or suboptimal.
