[ZIP 272]: Zcash Consensus Accounts #1162
Conversation
Co-authored-by: Kris Nuttycombe <kris@nutty.land>
str4d
force-pushed
the
consensus-accounts
branch
from
3b85ce1 to
f9dc255
Compare
nuttycom
changed the title
nuttycom
changed the title
|
|
||
| The Zcash development fund lockbox currently has the characteristics of a transparent, account-based system. Spending from the lockbox requires the introduction of a new transaction bundle that treats the lockbox as a source of transaction inputs, controlled by a key that may be rotated using the mechanism specified in ZIP 270 [^zip-0270]. Instead of creating a mechanism that is specific to the development fund lockbox, creating a general mechanism provides several benefits to consistency and usability. | ||
|
|
||
| Part of the rationale for the creation of the dev fund lockbox was that the process of shielding tens of thousands of development fund outputs (over a thousand outputs per day) has created excessive operational friction for key-holder entities; in addition, transactions that spend these outputs have significant fee costs under ZIP 317 [^zip-0317]. These disadvantages do not uniquely effect the key holders of the development fund, however; they are felt just as acutely by miners and Zcash Community Grants. By introducing an account-based system, all recipients of new issuance can gain the same benefits that are available to the keyholders of the coinholder-controlled fund introduced in ZIP 1016 [^zip-1016]. |
There was a problem hiding this comment.
(nit) s/of the rationale/of the motivation/
|
|
||
| The Zcash development fund lockbox currently has the characteristics of a transparent, account-based system. Spending from the lockbox requires the introduction of a new transaction bundle that treats the lockbox as a source of transaction inputs, controlled by a key that may be rotated using the mechanism specified in ZIP 270 [^zip-0270]. Instead of creating a mechanism that is specific to the development fund lockbox, creating a general mechanism provides several benefits to consistency and usability. | ||
|
|
||
| Part of the rationale for the creation of the dev fund lockbox was that the process of shielding tens of thousands of development fund outputs (over a thousand outputs per day) has created excessive operational friction for key-holder entities; in addition, transactions that spend these outputs have significant fee costs under ZIP 317 [^zip-0317]. These disadvantages do not uniquely effect the key holders of the development fund, however; they are felt just as acutely by miners and Zcash Community Grants. By introducing an account-based system, all recipients of new issuance can gain the same benefits that are available to the keyholders of the coinholder-controlled fund introduced in ZIP 1016 [^zip-1016]. |
There was a problem hiding this comment.
Although I'm not actually advocating for this, this motivation begs the question: why not allow the entire transparent ledger to make use of the account model? I can think of other non-consensus use-cases that would similarly benefit from an account model.
Ofc I can think of my own reasons not to make such a broad change, but as a reader of this spec, I would like to learn some rationale for restricting the account model to consensus accounts only.
There was a problem hiding this comment.
We certainly thought about this as a possibility, but given the can of worms, the thought is to restrict it to consensus issuance at present.
There was a problem hiding this comment.
Note that spends from Consensus Accounts are only controlled by a single public key signature. They are not a replacement for the transparent ledger, where spend authority is controllable by arbitrary Bitcoin-ish scripts (which we not going to import herein).
|
|
||
| - All new ZEC (and in the future, ZSA) issuance is credited to a transparent account. | ||
| - TODO: Should this be a requirement for ZSAs? str4d thinks no. | ||
| - Newly-issued ZEC is credited either to a hardcoded funding stream key (until block height 4476000 as specified in [^zip-0214], this will be either the coinholder-controlled-fund key or a to-be-defined Zcash Community Grants fund key) or to a miner-controlled key. |
There was a problem hiding this comment.
or to a miner-controlled key
Does the miner need to prove it controls the account it specifies? Or does this proposal allow any miner-specified account, even if they do not know the private key to control that account?
There was a problem hiding this comment.
Yes, the miner needs to prove it controls the account. I'll add a signature to the authorizing data for the bundle. I'm going to assume that this spec depends upon the extensible transaction formats ZIP.
|
|
||
| - All new ZEC (and in the future, ZSA) issuance is credited to a transparent account. | ||
| - TODO: Should this be a requirement for ZSAs? str4d thinks no. | ||
| - Newly-issued ZEC is credited either to a hardcoded funding stream key (until block height 4476000 as specified in [^zip-0214], this will be either the coinholder-controlled-fund key or a to-be-defined Zcash Community Grants fund key) or to a miner-controlled key. |
There was a problem hiding this comment.
(nit)
"Newly-issued ZEC is credited either" -> "Newly-issued ZEC is credited to an account controlled by either"
There was a problem hiding this comment.
To disallow hardcoded funding stream keys, we'd need to disallow V5 coinbase transactions. I think that might be a reasonable choice, but it would be a big upheaval for miners, who might currently be sending their mining outputs to a transparent P2SH multisig address.
| <th>Encoding</th> | ||
| <td>Implicit rule</td> | ||
| <td>Explicit UTXO</td> | ||
| <td>Explicit rule</td> |
There was a problem hiding this comment.
It took me a bit to understand that some columns are elided (coinbase explicit rule spends and Non-coinbase implicit rule spends). IMO it would be clearer to include those columns even if they are empty
|
|
||
| TODO: decide on and specify format of `consensus_account_id`. | ||
|
|
||
| Each consensus account has a ZIP 270 tracked signing key associated with it, that authorizes the spending of funds from the account. As of the current revision of this ZIP, the tracked signing key MUST be a RedPallas key. |
There was a problem hiding this comment.
Each consensus account has a ZIP 270 tracked signing key associated with it that authorizes the spending of funds from the account.
l think this needs an exception/clarification for miners' accounts
| Consensus accounts require the following additions to the global state: | ||
|
|
||
| - A map, `consensus_accounts`, from `consensus_account_id` to a current balance. | ||
| - TODO: Each consensus account has a single denomination? Or allow the complexity of multi-asset accounts? |
There was a problem hiding this comment.
Do we also need to store account nonces for replay prevention?
There was a problem hiding this comment.
Is your meaning that the nonce protects against the replay of the signature? The signature will be over the txid, which should mean that it commits to the block height in which the block is mined. I'd like some clarification on your question here.
There was a problem hiding this comment.
I'm talking about transaction replay prevention. So, if someone makes a payment from a consensus account (e.g. a mining pool makes a payout from their account), could that transaction be replayed multiple times to authenticate multiple identical payouts that the mining pool did not intend?
Other account-based ledgers store an account nonce and require transactions to have the latest nonce, in order to prevent multiple inclusions of a transaction.
This commit resolves design decisions and adds detailed specifications: - Decide ZEC-only for initial implementation, with format reserving space for future ZSA support via assetClass/assetId fields - Retain shielded coinbase outputs alongside consensus accounts - Define consensus_account_id as BLAKE2b-256 hash of protocol type and initial public key, stable across key rotations - Specify account registration bundle (no value, requires signature) - Specify consensus account output bundle (credits value, no auth) - Specify consensus account spend bundle with shielding requirement - Add consensus rule: coinbase registrations require corresponding outputs - Add ZIP 270 key usage typecode for consensus account spending - Update ZIP 207/214 changes for funding stream migration - Add Protocol Specification changes for global state and consensus rules - Add Rationale and Alternatives sections - Fix inconsistencies and add missing references Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
nuttycom
force-pushed
the
consensus-accounts
branch
from
95b3908 to
b1b8406
Compare
daira
changed the title
3 participants
No description provided.