Thanks @dodgers. Hearing programmability is a long term goal is very exciting.
I also completely agree with @David_Heisenberg. So let me start. I’m open to anyone making other suggestions. Just an open discussion to try and get some ideas about what the community things should be a good goal around this.
DeFi
I think at least in the initial iteration I think it’s fair to look at calls for programmability as a call to enable DeFi. I think a broad initial goal would be to enable native defi in as many forms as possible.
Initial Types of DeFi
- Native exchanges
- ZEC backed assets
- Collateral and Lending
- Mutual Funds
- Insurance
Feature Requirements for DeFi
- Tokens (ZSAs)
- Asset locking
- Rollups/Sidechains
Optional/Future:
- ZSA Addresses (DAO like structures)
Enabling ZSAs, Asset Locking, Rollups/Sidechains
In Ethereum the ERC tokens, asset locking, and rollups are all made possible with programmable smart contracts. We could go down this same route too. But I’d argue we’d be better served enabling these as core features of Zcash. We’ve already started with ZSA development underway. I advocate ZF research and explore the possible options for enabling asset locking and sidechains.
Let me attempt to make a start at discussing these topics.
Asset locking
The issue with asset locking isn’t the locking of assets, rather, the ability to trust they will be unlocked/transfered under a set of conditions. I can think of two obvious ways to achieve this.
- On-chain programmable concensus (e.g. smart contracts)
- Partial on-chain threshold consensus (e.g. ZSA Addresses - see below)
- Off-chain threshold concensus (e.g. multisig or FROST - see below)
Off-chain FROST
My high level (noob) understanding is we could achieve some form of asset locking with a decentralised set of nodes all participating in producing a signature using frost. A special FROST address would accept assets. The FROST participants/nodes would be incentivised to do the right thing and unlock/transfer the assets when the appropriate condition is met or be penalised if they don’t. In many ways we could think of this as a form of off-chain programmability.
Luckily for us ZF has the very expert to advise on these matters (@dconnolly).
Rollups/Sidechains
It has become clear that L2 solutions (like Rollups) are almost certainly part of the scaling solution in the near term. In Zcash that might mean enabling sidechains. For sidechains to become effective we might need a couple of things.
- The ability to batch and merge a large number of transaction in a more efficient (and cheaper) manor.
- An easy step by step method to start a new sidechains
I think making this easy is key. How easy can we make it? Can we make it so that a user simply runs zebrad with a set of flags to start a new sidechain? Making it so easy that every blockchain developer cant help but try it might be a key to increasing adoption and experimentation.
Also do we want sidechains to be mostly compatible with existing wallets and tools? Will some sidechains want users to connect and transact using their existing wallets/tools? Can a wallet simply connect to a sidechain and transact as they would on the main chain?
Are ZSA Sidechains Secure?
My understanding is that from a security perspective we need to limit the leaked information from transacting on a “forked” chain which could leak information about the parent chain. This would mean a sidechains (at least presently) would need to transact using assets not available on the parent chain. One way around this would be for assets to be “issued” on the sidechains only once the assets have been locked on the parent chain.
There may still be some additional privacy concerns here but I believe they are more related to the size of the anonymity set potentially being smaller on the sidechains. But I’m no expert, just pondering out loud .
ZSA Addresses
I envisage ZSA Addresses are special addresses that are collectively controlled by the asset holders. Assets can be transfer into a ZSA Address by anyone. A predefined threshold could be set to require weighted consensus by asset holders before transfering (or issuing) assets.
This would enable a POS like systems where a ZSA Address is controlled by the ZSA holders who are running nodes. These nodes would be incentivised to do the right thing and transfer the funds somewhere once a certain set of rules (could be on-chain or off-chain) are met. In many ways this is a form of off-chain programmability.