@LeCryptoMath Very well written post!
I’m a big supporter of having broad utility for ZSAs. I have only been thinking about this for a short time but have been pondering how much utility we can achieve from a small set of generic ZSA transaction types/features (e.g. ZCash programmability vs L2 using ZSAs).
I’ll try and simplify some functionality I’ve been thinking on below but I’m hoping that by using this simple base we could then offload any more advance features (like programmability) onto L2 POS style chains that using ZCash ZSAs as their L1…
ZSAs minting/transacting other ZSAs
Scenario 1 - Minting Token
A single user mints a “Minting” asset.
A new “IOU” asset is created and the “Minting” asset is assigned as the “allowed minter” with a 100% weighted threshold for minting. Since there is only 1 Minting token any minting request is 100% weighted and is automatically valid.
The user can transfer the minting token to other addresses which can then be used as the address to mint IOUs.
Scenario 2 - Multiparty Minting Tokens
Four “Minting” token assets are created. 3 joint business owners share the tokens. User 1 is assigned 2 assets while user 2 and 3 are assigned 1 each. The Minting token assigns itself as the “allowed minter” requiring 100% weighting to mint more (e.g. all parties must agree to mint more minting tokens).
A new “IOU” asset is created by the company for assigning IOUs to contractors. The “Minting” asset is assigned as the “allowed minter” with a 51% weighted threshold for minting. Since there are 4 Minting tokens any minting of IOU requires at least 3 of the 4 tokens are required to mint new IOUs.
Scenario 3 - Multiparty Minting Tokens using On-chain “voting”
100 anonymous users are giving 1 “Minting” token.
A new “IOU” asset it created and assigns the “Minting” token as the “allowed minter” and requires 50% weighted threshold for minting. Since the anonymous users don’t know each other they have to “register” their vote to mint on-chain with a new “transaction type” (e.g. vote/sign). I like the pseudo “sign” analogy since we can think of them as signature objects that possibly have things like valid after/before timestamps.
If the 50% threshold is reached the tokens are minted.
Scenario 4 - L2 programmability using ZSAs
100 stakers all run a “ZCompute” (fictional programable L2) node while holding/staking/locking “ZCompute Staking” tokens.
The staking tokens have “minting” and “transaction” rights for the ZCompute tokens and require at least 50% vote for minting and/or transactions to occur. As they compute (or verify a compute/proof) they place their votes for minting or transacting tokens.
Additionally to this ZCompute staking tokens need to be “lockable/destroyable/0x0 transferable” to disincentivize bad actors. Stakers can vote to “destroy” staker tokens from bad actors.
@LeCryptoMath I’d be interested to know your thoughts on this and if this is a feasible end goal :).