ZCash programmability vs L2 using ZSAs

[GGuy]

I’ve been pondering if ZSAs are all we need for L2/ERC20 like scenarios.

@GGuy

Scenario 2 - Level 1 as a Service

A community of people decide their new awesome blockchain idea is should provide privacy for all. They decide L2 proof of stake is the way to go and they can do that using ZCash.

All members are distributed their share of “currency” and “staking” assets. They configure a consensus rule for the currency ZSA that only allows a currency transfer to occur if 50% of stalking value sign the transaction. Each staker node enforces the awesome blockchains consensus rules and signs the transaction if appropriate.

Now that we’ve seen how Ethereum and ERC20 (and alike) tokens play out is worth discussing are the pros and cons of structuring/marketing/experimenting with ZSAs for POS L2 chains as a replacement to on-chain programmability? And if ZCash did want programmability would it be better done at L2 using a new ZSA asset “controlled” by a seperate system (e.g. ZCompute with ZComputeD nodes)?

1st pro to having programmability on an L2 would be how much faster you could iterate not having to worry about breaking L1 consensus.

[tokidoki]

Love this idea. I think one big potential use-case of ZSA is Zcash becoming the choice for any community of any chain to store their tokens/treasury. This aligns nicely with @zooko “privacy comes from money at rest” idea.

[GGuy]

So to make this happen I guess a few new ZIPs have to exist? I’d have to think about this properly but I’ll put my thoughts out there for feedback .

1. Multisig halo2 transactions
2. Stake weighted multisig
3. Meta actions
4. Asset as signee
5. Pool locked assets

Where

1. multisig where 1 sig per staker
2. weight signatures based on number of assets
3. an L2 node needs to sign a multisig action on the stakers asset that triggers a currency asset action (e.g. each L2 node triggers a stalker asset “vote” which in turn might trigger a currency action).
4. a stalker asset should be able to trigger an action (E.g. forced burn of assets from bad staker)
5. assets should be lockable to a specific pool (e.g. halo 2, transparent). Maybe staker assets have to be transparent anyways otherwise we can’t watch/discover bad actors?

I automatically imagined that L2 as a service means you want stakers to “vote” on chain by interacting with staker tokens signing “actions” to control the underlying currency (or other asset). Not sure if there is another way…

[pkr]

+1 on point #5. I think all the talk on deprecating T-addresses would ultimately be throwing away the baby with the bath water and this is a good reason why – they would be very useful for auditing of bad actors.

[tokidoki]

Off-topic but I think the biggest problem on t-addresses is its scalability. Personally, I would not want to add more features that depend on bitcoin scripts, as those will need to be changed. If the built features were then adopted and used, it will be very hard then to deal with scaling the blockchain while trying to remove legacy features (that depend on legacy bitcoin scripts). In the times of future scaling debate, this will likely result in Zcash community to be divided into 2 camps:

1. Progressives: Remove t-addresses and features that depend on it.
2. Conservatives: Keep things as is and let’s find ways to scale Zcash on L2 or sidechains.

To be clear, I am talking about future problems that may arise from adding new features that depend on t-addresses (at least in their current implementation). If we truly want a way to easily audit something, we can choose two roads: better viewing key mechs OR a new modern “transparent pool” that is designed to be as scalable as modern Zcash pools.