HIP-1139: Enable Immutable Topic Ids and Updatable Submit Keys without an Admin Key.

Abstract

The Hedera Consensus Service (HCS) provides topics that may have opt-in administrative keys (Admin Key) and submission control keys (Submit Key). Currently, once these keys are set during topic creation, there is no mechanism to transition them to an immutable state. Additionally, there’s no way for a Submit Key to update itself without an admin key. This proposal seeks to enable topics to be made fully immutable by setting Submit Keys to dead (unusable) keys or modifying themselves to another key and providing a mechanism for Admin Keys to be made permanently unusable, bringing HCS topic key management in line with capabilities in other Hedera services such as the Token Service (HIP-540).

Motivation

Many applications require immutable topics for their use cases, yet some project owners have unknowingly created topics with keys such as Admin Key and Submit Key set, which undermines this assumption. Through extensive testing, we have identified several key limitations in the current HCS topic key management:

1. No Path to Immutability: Once a topic is created with keys, there is no way to transition it to a fully immutable state. Our tests demonstrated that a submit key can ONLY be updated if an admin key is present.
2. No Path to Update Submit Keys: Once a topic is created with a Submit Key Only, there is no way for it to remove or update itself. This presents security and immutability risks.

3. Critical Admin Key Limitation: The most significant limitation we discovered is that Admin Keys cannot be set to dead (unusable) keys directly, because:

   • Admin Keys need to sign their own update transaction
   • A dead key cannot provide a valid signature
   • This creates a circular dependency that prevents making Admin Keys permanently unusable
   • We need a special mechanism to make Admin Keys permanently unusable

4. Submit Key Limitations: While Submit Keys can be updated by Admin Keys, we discovered in testing that:

   • Setting Submit Keys to dead (unusable) keys is possible but requires Admin Key authorization
   • This is critical for making topics completely immutable by preventing any future message submissions
   • Without the ability to make Submit Keys unusable, topics remain writable even if administratively immutable
5. Inflexible Key Updates: Our tests showed that while key updates are possible, there is no standardized mechanism to:
   • Make Admin Keys completely unusable (they can’t be set to dead keys)
   • Make Submit Keys completely unusable to prevent future message submissions
   • Transition a topic to a fully immutable state where no operations are possible

These limitations force developers to either recreate topics (losing message history) or implement workarounds that may not be ideal for production environments.

Rationale

Based on our testing and analysis, we propose enhancing topic key management for several reasons:

1. Alignment with HIP-540: The Token Service already provides mechanisms for making keys permanently unusable through HIP-540. HCS should provide similar capabilities for consistency across Hedera services.

2. Development to Production Transition: Our tests confirmed that developers need the ability to:

   • Start with administrative controls for testing and setup
   • Make Submit Keys completely unusable by setting them to dead keys
   • Ensure no future modifications are possible once in production

3. Key Management Options: Through our test cases, we identified common scenarios that require true immutability:

   • Converting a managed topic to a completely immutable one, for example with HCS-1.
   • Making Submit Keys unusable to prevent any future message submissions
   • Making Admin Keys unusable to prevent any future administrative changes

4. Error Recovery: Our testing revealed that developers who accidentally set keys during topic creation currently have no recourse except to create a new topic and migrate all messages.

Language

Let’s address important language to set a clear distinction between key states:

• “Dead Key” refers to an all-zeros Ed25519 public key that is cryptographically impossible to sign with.
• “Topic Immutability” refers to a state where both the Admin Key and Submit Key are unusable, ensuring no future modifications or operations are possible, but the Topic remains in Consensus Nodes (and block nodes in the future).
• “Key Immutability” refers to making a key permanently unusable, either through setting it to a dead key (Submit Key) or through a special call.

User stories

Based on our testing and real-world scenarios, we have identified the following key use cases:

• As a developer, I want to make the Admin Key permanently unusable on my existing topic so that it becomes administratively immutable.

• As a developer, I want to set the Submit Key to a dead key on my existing topic so that no further messages can ever be submitted.

• As a developer, I want to transition my topic from a managed state to a fully immutable state by making both keys unusable.

• As a service provider, I want to create a topic on behalf of a user with our private key as the Admin Key, and then make the Admin Key permanently unusable, ensuring no future administrative changes are possible.

• As a service provider or Mirror Node, I should still be able to query all messages from a topic with dead or unstable keys (no change from current functionality)

Specification

Based on our testing and discovery of the Admin Key limitation, we propose the following changes:

1. Key Immutability Mechanism:

   • Submit Keys can be set to dead keys (all-zeros) to make them permanently unusable
   • Admin Keys require a special mechanism to be made permanently unusable since they can’t be set to dead keys
   • Once a key is made unusable, this operation must be permanent and irreversible

2. Implementation Flow:

// Make Submit Key unusable with a dead key
const deadKey = PublicKey.fromBytes(new Uint8Array(32));
await new TopicUpdateTransaction()
  .setTopicId(topicId)
  .setSubmitKey(deadKey)
  .freezeWith(client)
  .sign(adminKey);

1. State Transitions:

   • A topic with both keys made unusable is fully immutable
   • A topic with Admin Key made unusable but with an active Submit Key has immutable administration but allows signed submissions
   • A topic with Submit Key set to a dead key but with an active Admin Key prevents message submissions but can be administratively updated

2. HAPI Changes: The TopicUpdate transaction will be modified to:

   • Support setting Submit Keys to dead keys (all-zeros)
   • Ensure these operations are permanent and irreversible

Backwards Compatibility

This change is fully backward compatible and opt-in:

1. Existing Topics:

   • Topics without keys remain unaffected
   • Topics with keys continue to function as before
   • No automatic migration is required

2. SDK Compatibility:

   • Existing SDK methods continue to work
   • Key immutability functionality is additive
   • Dead key support and Admin Key immutability mechanism are new features

Security Implications

Our testing revealed several security considerations:

1. Key Management:

   • Admin Key remains the highest privilege key until made unusable
   • Admin Key immutability are permanent and irreversible
   • Proper key custody remains critical until intentional transition to immutability

2. Attack Vectors:

   • An attacker with Admin Key access could make keys unusable, but this would also permanently lock them out
   • No new attack vectors are introduced
   • Dead keys provide cryptographic guarantees of immutability

How to Teach This

Based on our implementation and testing, we recommend documenting the following patterns:

// Example: Complete immutability transition flow

// 1. Create a topic with both keys for development
const topic = await new TopicCreateTransaction()
  .setAdminKey(adminKey)
  .setSubmitKey(submitKey)
  .execute(client);

// 2. Make Submit Key unusable with dead key
const deadKey = PublicKey.fromBytes(new Uint8Array(32));
await new TopicUpdateTransaction()
  .setTopicId(topicId)
  .setSubmitKey(deadKey)
  .sign(adminKey)
  .execute(client);

// 3. Make Admin Key unusable for complete topic immutability
await new TopicUpdateTransaction()
  .setTopicId(topicId)
  .setAdminKey(deadKey)
  .sign(adminKey)
  .execute(client);

Rejected Ideas

1. Empty KeyList Approach: Using empty KeyLists was considered but rejected because it effectively makes the topic public and writable.
2. Deleting a topic: Deleting a topic would make it immutable, but confusing to service providers and block nodes in the future. It should be possible to keep a topic in state while not making it writable.

References

• HIP-540: Change Or Remove Existing Keys From A Token
• Hedera API - Consensus Service
• SDK Documentation - Create a Topic
• SDK Documentation - Update a Topic

Copyright/license

This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

Citation

Please cite this document as: