Consistent ability to remove admin & privileged keys

[Cooper-Kunz]

Authors

Cooper Kunz
Jason Fabritz

Abstract

All entities across Hedera have opt-in administrative keys. Currently, the Consensus Service and File service allow these keys to be removed (making the entities immutable). However the Contract and Token Services do not provide such a feature consistently. We should enable existing administrative keys and other privileged keys for these entities to be able to sign an update transaction that permanently removes the keys from their privileged permissions.

Motivation

Less admins > More admins. Give folks tools to decentralize yourself over time.

Rationale

Currently you’re either in an admin world, or an admin-less world, on Hedera. It’s often preferable to launch in an administrative capacity to ensure things are operating smoothly, and transition into a more admin-less world overtime.

Specification

Adding this feature requires no changes in existing HAPI protobuf structure, as the respective update transaction body messages already in existence provide the required properties to represent the desired behavior.

All that is required is for the Hedera Network to recognize an Empty KeyList key as a sentinel value to indicate that the key should be removed from the entity. The following keys shall support this feature:

For token entities, the following TokenUpdateTransactionBody message properties:

• adminKey
• kycKey
• freezeKey
• wipeKey
• supplyKey
• fee_schedule_key
• pause_key

For contracts, the following ContractUpdateTransactionBody message properties:

• adminKey

Additionally, in order to facilitate a progressive transition to immutability, for an entity, once a key has been removed from a contract or token definition, it may not be put back. In other words, a key, such as a mint key can be swapped for any other existing key (assuming the object has an admin key of course), including erasing the key from the definition. But once a key has been erased, it may not be added later.

It should be allowed to remove the adminKey from an entity within the same transaction that removes another type of key (a wipeKey for example), so long as the entity had a valid adminKey prior to executing said transaction.

Backward compatibility

This change is fully backwards compatible & opt-in. Existing entities that have been created with administrative keys can continue operating as desired. Entities that have been created without administrative keys can continue operating as desired. The use of an empty KeyList in an update transaction for these entities currently generates an error response, enabling it to represent a sentry value will be forward compatible.

Security Implications

Generally with administrative keys there are security requirements about how to secure and manage these secrets. This becomes increasingly important with this change, as a potential attacker could gain access to the admin keys and subsequently remove them from the entity - however, this would effectively lock/freeze them out, as it would the original administrator. These security considerations are not unique to this proposal and generally consistent with all keys attached to entities within the Hedera network.

How to Teach This

If you want to remove an admin or privileged key from any Hedera network entity, you can submit an AccountUpdateTransaction that replaces the existing key with an empty KeyList - this transaction will result in an entity no longer having an admin (or whatever key was hoping to be replaced).

[justynspooner]

@Cooper-Kunz @bugbytesinc apologies, I've only just seen this discussion. I recently submitted a HIP proposal which is almost identical to yours! #540

I had a chat with @mgarbs and he suggested linking back to this discussion from the HIP I've submitted.

Shall we combine forces and get this pushed through? I was mainly focussing on HTS but you raise a good point with contracts having the same issue. I'll update the HIP to reflect the contract admin key removal as well.

Please also feel free to jump in and add comments/suggestions. @Ashe-Oro and @mgarbs have also been helping get it into a review state.

[Cooper-Kunz]

For @mgarbs - the HIP requests a new item being added to the network, specifically an "emtpy key constant" + changes to all SDKs

1. Introduce a constant to represent an empty key. This will be used as part of the token and/or contract update calls to remove existing keys.

2. Update all other areas of the SDK that make use of an empty key to use this new constant for consistency.

Informational HIPs are defined as the following -

An Informational HIP describes a Hedera design issue, or provides general guidelines or information to the Hedera community, but does not propose a new feature. Informational HIPs do not necessarily represent a Hedera community consensus or recommendation, so users and implementers are free to ignore Informational HIPs or follow their direction.

Obviously contradictory.... Further it would say that myself, SDK, and application devs, can ignore it. Which isn't the case.

[mgarbs]

The intent here with my Informational suggestion was to have a standard with a "trash key" that SDKs could adopt. I was trying to steer it in this direction because the actual key removal may have unintended consequences. Take, for instance, a KYC key scenario. A contract could be using KYC and a disgruntled employee who used to have access to that key could remove it and mess up the original contract. There may be legal issues with this case, but I'm not a lawyer.

There was a further conversation that updated keys may need to sign the tx, so you don't ever really fix the problem with a trash key. In any case, I would like to note this in this discussion.

[Cooper-Kunz]

Could you please link me to the discussion you had around changing it to an optional SDK standard?

[Cooper-Kunz]

Also generally, I think we are well aware of the potential consequences. You could say the same is true for all key mgmt. A disgruntled employee could mint an infinite amount of tokens with a supply key, etc. That is not unique to this proposal. So I'd say it warrants further discussion (hence me asking for where you presumably already discussed it publicly with multiple community members).

[mgarbs]

Could you please link me to the discussion?

These were internal calls where I suggested this and then relayed that suggestion to @justynspooner in dms. There is a review going on for this HIP you may want to have a peep at. Your feedback would be valuable. For instance, this question #540 (comment)
Also- I added you as an author and linked this discussion in the HIP. Thank you @Cooper-Kunz you're awesome! :)

[kantorcodes]

Agreed with everything in here!