Potential ZSA requirements to support RenVM

[nathan-at-least]

I'm dumping some unrefined notes here from a call on 2021-09-14 with some ECC & RenVM folks about technical requirements for ZSAs to integrate with the RenVM bridge:

• RenVM:
  • Source assets
  • Output chains
    • EVM compatible + Solana
    • EVM & Solana mean at least two “output chain” instances are already in RenVM.
  • RenVM can generate an ecDSA signature when conditions are met.
• ZSA-Zcash could be an output chain.
• Output Chain Requirements:
  • Minting:
    • Receive an authorized “Mint Message”, signed by renVM, bound to: (selector, user-output-chain-address, amount, app-specific-payload, nonce)
      • Signed w/ ecDSA secp256k1
      • Selector identifies source->destination chains.
      • Nonce - to prevent front-running some chains (?)
    • Output chain must issue X of target asset to destination address.
    • Output chain must ensure the same Mint Message may never be honored more than once (no replay). Ren output contracts track this; in Zcash we might be able to integrate into nullifiers.
    • Output chain must verify the ecDSA secp256k1.
    • Output chain must support ecDSA secp256k1 key rotation system where previous keys sign subsequent addresses.
  • Redemption:
    • User sends X renBTC to the Ren redemption contract, which burns them.
      • Output chain emits EVM event, Solana chain emits a log.
      • RenVM queries full node events/logs.
    • Zcash requirements:
      • Redemption operation must include:
        • Amount of asset to be redeemed.
        • Recipient on destination chain (ex: renBTC redemption destination chain is Bitcoin)
        • “Burn Nonce” (a sequence number) that’s unique for a given asset type on the output chain (and increments)
      • We determined for renvm redemption info must be public (since any renVM node must be able to validate the output and anyone can run a renVM node)
• Cross-chain asset identification:
  • On Ethereum, there are distinct redemption contracts for each asset type (renZEC, renBTC, etc…) and the contract address is used to identify the asset.
  • How is a user-friendly asset name associated with a new asset type when it is created?
• Multi-asset <-> multi-asset bridging:
  • Future feature (launch in about 1 week): any ERC20 chain or Solana <-> any ERC20 chain or Solana.

[daira]

I'm making this block the ZSA specs not because it is a requirement, but just because it should be taken into account when reviewing those specs.