---
# System prepended metadata

title: Zcash <-> Polkadot Bridge Spec Sheet

---

# Zcash <-> Polkadot Bridge Spec Sheet
:::warning


3. Problem: We don't have the end in mind of what exactly that we need to submit to Polkadot.
    * Solution: Copy all content from Google Form + specific deliverables specific to the spec sheet track in one document to get the final picture of what exactly is needed. 

This document defines requirements of submission for RFP application link : https://docs.google.com/document/d/1Sy3uJotYWQcDZQqPGVBrYSb2uwNQkR3eVySKIxOnW5o/edit?usp=sharing


1. Problem: Meat of the proposal is not ready. 
    * Solution: 
        * Identify where we currently stand: Judge the proposal by rating content on a scale of 1 - 10 where 10 is the knowledge that exists in your mind and the score you give is the content that's put down in the proposal. 
        * From above: Prastut will take lead to get the score on 10 to extract content from Shivam. 

2. Problem: Milestones are not ready. 
    * Solution: Identify milestones from EOS and modify them to suit our proposal needs. 

     

:::


## Project Description
This application is in response to Polkadot Bridges RFP : https://docs.google.com/document/d/1yMpiSAAvGeRebLlzl5fmcq_LloIViperTw4UUEuQYzM/edit
:::warning

Required under Grants tempelate.

Please provide the following:

* A brief description of the project.
* An indication of why this project is good for the ecosystem.
* An indication of how you will integrate this project into Substrate / Polkadot.
* An indication of why your team is interested in creating this project.

:::

We aim to write full specification and minimal PoC for a cross platform bridge for seamless interoperability between Zcash and Polkadot enabling secure, flexible and scalable cross chain payments. (like http://btcrelay.org/ : Bridge between BTC and ETH) and to enable users to achieve interoperability between Zcash and Polkadot chain in performing following operations: 
1. Issue
2. Transfer/Swap
3. Redeem

of cryptocurrency assets across the respective chains. While achieving the design objectives :

1. Safety
2. Liveness
3. Consistency
4. Redeemability
5. Auditability
6. Scalability

Current Market Cap of Zcash stands at $472,456,902 USD (as on 5 march,2020 source: https://coinmarketcap.com/currencies/zcash/)

Zcash and other PoW chains have high liquidity but small scope of operations, majorly storage of value, investing and trading. Bridge will be critical to exchange of crypto assets and creation of fund flow between Zcash and Polkadot, opening gates to numerous applications while leveraging proven privacy features of Zcash and Polkadot Scalability.


The future long term vision is enablement of :

1. Replacement : Cross Chain payment channels by off chain participation while avoiding need of publishing every transaction on chain.
2. DEX : Decentralized Exchanges for trading of cryptocurrency assets over trustless platforms.
3. Potential use cases in Dapps and DeFi 

Inspirations are drawn for this project from Xclaim protocol : [XCLAIM: Trustless, Interoperable, Cryptocurrency-Backed Assets](https://eprint.iacr.org/2018/643.pdf)

We have acquired vantage and exposure in Zcash and Polkadot communities by shipping out projects, which motivates us to pursue further grants.


## Team Members
**Members :**
* Prastut Kumar (Project Manager) [EMAIL](prastut@thevantageproject.com) 
* Shivam Khare (Blockchain Researcher) [EMAIL](shivam@thevantageproject.com) 
    
**LinkedIn Profiles:**

- Prastut Kumar - [https://www.linkedin.com/in/prastut/](https://www.linkedin.com/in/prastut/)
- Shivam Khare - https://www.linkedin.com/in/shivam-khare-a624308b/



## Team Experience

:::warning
Please describe the team's relevant experience. If the project involves development work, then we'd appreciated if you can single out a few interesting code commits made by team members on their past projects. We'll glance at whole repositories too, but not if they contain many vendored dependencies, which often makes commits easier.
:::
- [Zcash SSD](https://www.zcashservicestatus.info/d/kTk4wvvWk/home)  - A healthcheck + monitoring dashboard for the Zcash community
- [Polkabot](https://twitter.com/Polkabot5) - Twitter Bot for Relaying Polkadot protocol updates.
- [PolkaAnalytics](https://polkanalytics.com/#/dashboard) - Aiming to provide high integrity & structured info for @polkadotnetwork. Combines visual analytics + rewards calculation under one hood.
- [PolkaViz](https://polkavizproject.surge.sh/#/) - Visualization efforts for the Polkadot ecosystem. Currently visualizing action on the Kusama network.

## Team Website
http://buidllabs.io/

## Team Repository
https://github.com/buidl-labs


## Zcash <-> Polkadot Bridge (Technical Specification)

The 2 bridge participants are : Zcash parent chain and Polkadot parachain, which collect and synchronizes transactions between them with shared security to create secure, flexible and scalable bridge chain.

The critical component to achieve this is Bridge Chains under Polkadot network , which are special parachains that allow communication to independent blockchains that are not secured by Polkadot's relay chain.

Also, in accordance with the iSC (issuing smart contract) under Xclaim, here Bridge contracts will be implemented. The bridge is a combination of two smart contracts, one deployed on each chain, that allow for cross-chain transfers of value.

Bridge contract deployed on Polkadot parachain interacts with Zcash chain, through messaging services provided by in built bridging modules by converting Zcash chain to virtualized parachain.

Bridge contract will have following features :
1. Vault : for staking of tokens during collateralizations and storing CBA’s (Cryptocurrency Backed Assets) over cycle of transaction and exchange rate stabilization.
2. Exchange rate oracles : updation of exchange rate between issuing and backing tokens.
3. Parent Chain Registration : Includes registration of parachain, registration of each validator’s information, preventing receipt of data from forged sites
4. Parent chain block state validation/Parent chain transaction mapping - via collators and validators
5. Tribunal : promoting honest behavior using incentivization/penalization to actors and ensuring redeemability via deferred collateral withdrawal + collateralized issue commitments.
6. Relaychain : interconnect between blockchain and issuing smart contract (iSC) to maintain information about current chain state.

NOTE : Collateral amounts will be adjusted under floating exchange rates provided by [Chainlink](https://chain.link/)

:::warning
NOTE : Should we use smart contracts or bridge modules ? susbtrate doc on this  (https://substrate.dev/docs/en/next/conceptual/runtime/contracts/)

and info on light clients  : https://www.parity.io/what-is-a-light-client/
:::
 
## Zcash <-> Polkadot Bridge (Security Analysis)


The following provisions are being made in bridge for qualifying design requirements specified in (https://docs.google.com/document/d/1yMpiSAAvGeRebLlzl5fmcq_LloIViperTw4UUEuQYzM/edit)


### 1. SAFETY  :

:::warning
Confidence Rating: 8/10
:::

* #### (bridge should admit finalized transaction from external blockchain) - 
Only finalized transaction will be admitted to bridge, because chainRelay is capable of interpreting state of external Blockchain through storing and maintaining block headers and performing the functions of :
a) Storing block headers of every block from external blockchain verifying the inclusion of finalized transaction and transaction data itself into corresponding external chain
b) Any given block header can be verified that it’s part of external chain and has been agreed upon by majority consensus. 

* #### (In the event of a 51% attack on the external blockchain,  it should not be possible to manufacture assets on the bridge parachain where the equivalent asset was not collateralized on the external blockchain) -
Under Collateralized issue commitments we introduce a registration step to setup phase for issuing |i(b)| where requester must register an issue request with iSC (issuing Smart Contract), which temporarily locks corresponding amount of vault collateral, which ensures that equivalent collateral already exists on parachain before manufacturing assets on issuing chain. The iSC therefore only accepts pre-registered issuing attempts.

* #### (In the event of a 51% attack on the external blockchain,  It should be possible for bridge actors to detect attacks and respond by delaying finality of manufactured/redeemed bridge assets or by suspending transactions completely until the issue is resolved) - 
Under Deferred Collateral Withdrawal, we derive a simple announce-delay withdraw scheme to prevent such attacks. Specifically, we require the vault to announce collateral withdrawal publicly via the iSC (issuing Smart Contract). The iSC allows users to finalize (in theory also to initiate new) issue processes within a delay : ∆withdraw , after which the vault may withdraw the remaining unused collateral. Thereby, the lower bound for ∆withdraw is the upper bound on transaction inclusion proofs ∆relay where:

> ∆withdraw > ∆relay.
> 
> ∆relay = delay between block generation for transaction T on backing blockchain ‘b’ and block header submission + transaction inclusion proof for the transaction.
 
* #### (In the event of an attack on the Polkadot relay chain finality,  it should not be possible to redeem bridge assets to the external blockchain where such an asset never existed in the Polkadot network.) - 
In bridge design consideration it’s already noted that for redemption of assets i from issuing blockchain I equivalent to |i(b)|, a publicly verifiable transaction inclusion proof must be provided by backing blockchain B to the iSC, hence in absence of the legitimate assets on Polkadot network, such valid transaction proofs can’t be created.
 
* #### In the event of an attack on the bridge protocol (e.g. 51 % attack on the bridge relayers, As long as a single honest relayer exists, the attack should only have the potential to halt the bridge operation (i.e. harm liveness) but not have the potential to harm safety) - 
same as above, as consensus will not be converge to declare transaction inclusion proof as valid till a single honest relayer exists.


### 2. LIVENESS 
:::warning
Confidence Rating: 9/10
:::
#### (Every user should be able to obtain bridge assets as long as an equivalent amount of assets have been collateralized on external blockchain) - 
chainRelay makes Issuing of bridge assets non-interactive instead of trusting vault to confirm lock of b, by providing publicly verifiable proof of funds ‘b’ locked in vault where

> |b|= |i(b)|

now requester needs to prove to chainRelay that funds are correctly locked - presenting transaction signature generated when sending b to vault(B). If successfully verified, then only chainRelay triggers automated issuing of i(b) in iSC.

During redeem process it’s also important to verify 
>|b|=|i(b)|.

Hence transaction of b -> redeemer must be presented to chainRelay within maximum time delay Δ (Transaction inclusion verification), if failed to comply leads to financial penalty on collateral and iSC guarantees reimbursement to redeemer hence providing liveness.

To tamper with this arrangement, the agent must control all funds on I or prevent transaction inclusion verification in B or I. This is not possible because digital signature algorithm used in Bitcoin and for t - transaction in Zcash is ECDSA where signers collectively control ECDSA keypair and attacker will have to invert the hash function to recreate relationship between preimage and signed message digest in order to forge a signature.

### 3. CONSISTENCY :
:::warning
Confidence Rating: 10/10
:::
#### (The bridge is only able to issue assets on Polkadot if the equivalent value of the assets have been collateralized on the external blockchain.) - 
By construction design of our bridge protocol, iSC only issues i(b) if the provided transaction inclusion proof (publicly verifiable) shows that the correct amount on b was locked on B, 

> i.e., |b| = |i(b)|,

hence ensuring that an amount equivalent to b of backing chain, are collateralized in form of |i(b)| on issuing external chains.

### 4. REDEEMABILITY : 
:::warning
Confidence Rating: 10/10
:::

#### (Every user that owns bridge assets on Polkadot should be able to redeem them for the equivalent value of the asset that has been collateralized on the external blockchain.)

Vault inside iSC will ensure Redeemability under constant exchange rate by: 

* Deferred Collateral Withdrawal
* Collateralized issue commitments

iSC only accepts issue requests if collateral 
> i(col) ≥ b · ε(i,b)
> is locked by the vault
> where ε(i,b) = exchange rate between i and b

and during redeem protocol, vault is required to include a transaction in B, sending b to the redeemer such that
> |b| = |i(b)| 

and provide an inclusion proof to the iSC.

If the vault misbehaves, it will lose collateral i(col) , which the iSC uses to reimburse the redeemer

To ensure Redeemability under non-constant exchange rates, we hence 
1.  overcollateralize the vault
2.  enable adjustment of the vault’s locked collateral 
3.  introduce automatic liquidation to prevent financial loss in case of extreme devaluation of issuing token i.

Over-collateralization helps mitigate failures due to sudden drops of exchange rate by using buffer. As the vault can update collateral, it can, in the optimistic case, maintain secure operation of XCLAIM even if the buffer is depleted.

In long run, the adjustment of the vault’s collateral and introduce the notion of automatic liquidation of i(b) by the iSC.


### 5. AUDITABILITY : 
:::warning
Confidence Rating: 6/10
:::

iSC under Xclaim constructs secure audit logs on backing blockchain B and issuing Blockchain I to trace all actions in system and bridge. Publicly verifiable information is available in these logs which can be independently audited by external or internal agents. Also, Zcash is based on the peer-reviewed Zerocash protocol. (BLOCKAUDIT concept : https://arxiv.org/pdf/1811.09944.pdf )

Currently no vantage for auditing mechaism is available for bridge design.
Bridge architecture will include similar protocol to construct secure audit logs of both participant chains.


### 6. SCALABILITY :
:::warning
Confidence Rating: 5/10
:::

1. Kusama's block time is 6 sec
2. Polkadot mainnet timings are predicted to be in 3-10 sec range 

Source 
* https://medium.com/polkadot-network/polkadot-the-parachain-3808040a769a
* https://wiki.polkadot.network/docs/en/learn-parachains ,
* https://wiki.polkadot.network/docs/en/learn-faq)


3. Zcash recent upgrade of Blossom also cuts time to 75 sec and they also plan to increase scalability in the future. 

(Source : https://z.cash/support/faq/ , https://electriccoin.co/blog/blossom-upgrade-improves-speed-scalability-capacity/)

We lack the vantage on subject matter.
The proposed bridge architecture will be designed in line to accommodate the scalability parameters of both blockchains and operate accordingly.

## Development Roadmap
Milestone 1 - Feasibility research for design requirements - 1 month - $5k 
Milestone 2 - Kusama and Zcash network <-> Bridge contract compatibility test - 2 month - $10k
Milestone 3 - Polkadot <-> Zcash Bridge PoC Workflow + Design Document - 2 month - $15k
## Additional Info (References/Links)

1. What work has been done so far?
2. Have you applied for other grants so far?




