KIP-0014: Updated KIP-0012 Account Protocols

kip-0014/kip-0014.md

@@ -0,0 +1,102 @@
+---
+KIP: "0014"
+Title: Updated KIP-0012 Account Protocols
+Author: Stuart Popejoy [email protected], Doug Beardsley [email protected]
+Status: Draft
+Type: Standard
+Category: Chainweb
+Created: 2021-12-22
+---
+
+## Abstract
+
+Augment KIP-0012 account protocols with two new protocols, Guard Accounts and Rotatable Accounts.
+Modify KIP-0012 Single-Key Accounts to forbid rotation.
+
+## Motivation
+
+KIP-0012 introduced Account Protocols and the Single-Account protocol,
+as implemented in the KDA `coin` contract and elsewhere.
+KIP-0012 reserves all account names starting with `C:` where `C` is a single alpha protocol identifier.
+
+The KIP-0012 Single-Account protocol specifies `k:KEY` where KEY is a hex lowercase ED25519 public key.
+This functions to _reserve the account name_ on any chain which avoids problems like
+"squatting" where an account for a given name on one chain is grabbed by a malicious actor on
+another chain. `k:` has effectively neutralized this threat vector.
+
+However, `k:` is deficient in the following ways:
+
+### Rotation considered harmful for "k:" accounts
+
+Under `fungible-v2` and other standards, `rotate` is specified where an account guard can be
+changed. This presents a challenge to many systems that are accustomed to single-key standards
+on other blockchains such as Bitcoin and Ethereum where an "address" is irrevocably tied
+to a single key. As such this presents problems for "total chain analysis" of a given token
+using standard methods like tracking `fungible-v2.TRANSFER` events, which only provide account
+names and not guards.
+
+While rotation has proven useful with `k:` accounts, this is largely because `k:` makes _account
+reservation_ possible, but by allowing rotate, this robs the protocol from a significant benefit
+which is simplified and robust chain accounting.
+
+### Rotatable Accounts
+
+The solution proposed here is to (1) forbid rotation in `k:` accounts and (2) provide a "Rotatable
+Account" protocol explicitly for rotation. This allows token protocols that wish to forbid rotation to
+simply not support the Rotatable protocol.
+
+Rotatable Accounts specify `r:GUARD_HASH` where GUARD_HASH is the BLAKE2b256 hash of the canonical JSON encoding of
+the pact guard. At creation time the account is validated to have the hash of the provided guard.
+Rotatable Accounts unsurprisingly put no restrictions on rotation.
+
+### Guard Accounts: non-rotatable reservation for any guard type
+
+Reservation is obviously an essential feature, and currently `k:` accounts are used for this
+and then rotated to other guards. We observer that autonomous use cases like module guards lack
+_any_ method for reservation currently as they cannot produce a key-based witness.
+
+We propose "Guard Accounts" to add non-rotatable support for other guard types. Guard Accounts
+specify `g:GUARD_HASH` where GUARD_HASH is the BLAKE2b256 hash of the canonical JSON encoding of
+the pact guard. At creation time the account is validated to have the hash of the provided guard.
+Guard accounts are NOT rotatable.
+
+## Rationale
+
+Expanding reservation capability to all custody types is an obvious win, so Guard Accounts needs
+no further justification there.
+
+Restricting rotation is strongly opinionated, obviously. However we argue that non-rotatable `k:`
+and `g:` accounts follows a "principle of least surprise", given that single-key, non-rotatable custody
+is overwhelmingly the norm, leading to potentially dangerous confusion for users.
+
+The other big win of non-rotation is the dramatic simplification of total chain accounting and custody
+analysis. Indeed certain tokens that have higher tracking requirements for AML concerns etc can
+simply not support vanity and Rotatable accounts altogether, allowing them to confidently use the
+`fungible-v2.TRANSFER` event stream to populate any downstream datastores.
+
+Rotation uses the guard hash in order to support autonomous use cases (since single-key can obviously
+be supported in Guard and Rotatable accounts, as it is "just another guard").
+
+
+## Backwards Compatibility
+
+Since KIP-0012 already reserved all `C:` account names, there are no conflicts with the new protocols.
+Again since this only impacts account creation, there are no backcompat issues for existing accounts.
+
+Forbidding rotation from `k:` accounts means that users employing `k:` accounts for this use case should
+seek to migrate to other accounts such as "vanity" (non-protocol) and Rotatable accounts.
+
+## Specification
+
+Guard accounts are identified by `g:GUARD_HASH` where GUARD_HASH is the BLAKE2b256 hash of
+the canonical JSON encoding of
+the account guard. Rotation is forbidden.
+
+Rotatable accounts are identified by `r:GUARD_HASH` where GUARD_HASH is the BLAKE2b256 hash of
+the canonical JSON encoding of
+the account guard at creation time. Rotation is permitted.
+
+Rotation will be forbidden for `k:` accounts, except in the case where the account is being rotated
+back to the original key for those accounts that had been previously rotated.
+
+Implementation in Pact is TBD for this KIP.