From d15bdc06468c6687d8778b93e2fcac1eb766a28e Mon Sep 17 00:00:00 2001 From: Stuart Popejoy Date: Wed, 22 Dec 2021 15:19:47 -0500 Subject: [PATCH] KIP-0014: Updated KIP-0012 Account Protocols --- kip-0014/kip-0014.md | 102 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 kip-0014/kip-0014.md diff --git a/kip-0014/kip-0014.md b/kip-0014/kip-0014.md new file mode 100644 index 0000000..4973485 --- /dev/null +++ b/kip-0014/kip-0014.md @@ -0,0 +1,102 @@ +--- +KIP: "0014" +Title: Updated KIP-0012 Account Protocols +Author: Stuart Popejoy stuart@kadena.io, Doug Beardsley doug@kadena.io +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.