update abstract, motivation, add more deprecation details.

cardano-foundation · Nov 14, 2024 · 678c2bc · 678c2bc
1 parent cf3e00f
commit 678c2bc
Show file tree

Hide file tree

Showing 6 changed files with 55 additions and 16 deletions.
diff --git a/CIP-0105/README.md b/CIP-0105/README.md
@@ -105,13 +105,14 @@ These are also described in [CIP-0005 | Common Bech32 Prefixes](https://github.c
 
 DRep keys and DRep IDs should be encoded in Bech32 with the following prefixes:
 
-| Prefix        | Meaning                                                 | Contents                                                          |
-| ------------- | --------------------------------------------------------| ----------------------------------------------------------------- |
-| `drep_sk`     | CIP-1852’s DRep signing key                             | Ed25519 private key                                               |
-| `drep_vk`     | CIP-1852’s DRep verification key                        | Ed25519 public key                                                |
-| `drep_xsk`    | CIP-1852’s DRep extended signing key                    | Ed25519-bip32 extended private key                                |
-| `drep_xvk`    | CIP-1852’s DRep extended verification key               | Ed25519 public key with chain code                                |
-| `drep_vkh`    | Delegate representative verification key hash           | blake2b\_224 digest of a delegate representative verification key |
+| Prefix        | Meaning                                                 | Contents                                                           |
+| ------------- | --------------------------------------------------------| ------------------------------------------------------------------ |
+| `drep_sk`     | CIP-1852’s DRep signing key                             | Ed25519 private key                                                |
+| `drep_vk`     | CIP-1852’s DRep verification key                        | Ed25519 public key                                                 |
+| `drep_xsk`    | CIP-1852’s DRep extended signing key                    | Ed25519-bip32 extended private key                                 |
+| `drep_xvk`    | CIP-1852’s DRep extended verification key               | Ed25519 public key with chain code                                 |
+| `drep`        | [DEPRECATED] DRep verification key hash (DRep ID)       | blake2b\_224 digest of a delegate representative verification key  |
+| `drep_vkh`    | Delegate representative verification key hash           | blake2b\_224 digest of a delegate representative verification key  |
 | `drep_script` | Delegate representative script hash                     | blake2b\_224 digest of a serialized delegate representative script |
 
 #### Constitutional Committee Cold Keys
@@ -124,6 +125,7 @@ Constitutional cold keys and credential should be encoded in Bech32 with the fol
 | `cc_cold_vk`     | CIP-1852’s constitutional committee verification signing key          | Ed25519 private key                                                    |
 | `cc_cold_xsk`    | CIP-1852’s constitutional committee cold extended signing key         | Ed25519-bip32 extended private key                                     |
 | `cc_cold_xvk`    | CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code                                     |
+| `cc_cold`        | [DEPRECATED] Constitutional committee cold verification key hash (cold credential) | blake2b\_224 digest of a consitutional committee cold verification key |
 | `cc_cold_vkh`    | Constitutional committee cold verification key hash (cold credential) | blake2b\_224 digest of a consitutional committee cold verification key |
 | `cc_cold_script` | Constitutional committee cold script hash (cold credential)           | blake2b\_224 digest of a serialized constitutional committee cold script |
 
@@ -137,6 +139,7 @@ Constitutional hot keys and credential should be encoded in Bech32 with the foll
 | `cc_hot_vk`     | CIP-1852’s constitutional committee verification signing key          | Ed25519 private key                                                   |
 | `cc_hot_xsk`    | CIP-1852’s constitutional committee hot extended signing key          | Ed25519-bip32 extended private key                                    |
 | `cc_hot_xvk`    | CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code                                    |
+| `cc_hot`        | [DEPRECATED] Constitutional committee hot verification key hash (hot credential) | blake2b\_224 digest of a consitutional committee hot verification key |
 | `cc_hot_vkh`    | Constitutional committee hot verification key hash (hot credential)   | blake2b\_224 digest of a consitutional committee hot verification key |
 | `cc_hot_script` | Constitutional committee hot script hash (hot credential)             | blake2b\_224 digest of a serialized constitutional committee hot script |
 
@@ -201,7 +204,7 @@ For hardware implementations:
 | `ConstitutionalCommitteeHotVerificationKey_ed25519` | Hardware Constitutional Committee Hot Verification Key |
 
 ### Deprecated Governance ID Definition
-The previous governance key IDs defined by this have been upgraded as per the new specification introduced in [CIP-0129]. Tools implementing the following specification should gradually adopt the updated ID format outlined in [CIP-0129]. Tools that already support [CIP-0129] maintain backward compatibility with the legacy formats specified below but should consider fully transitioning to [CIP-0129] to standardize key formats across the ecosystem. This will help avoid multiple formats and ensure consistency.
+The previous governance key IDs defined by this standard have been superseded by the definitions provided in [CIP-0129]. Tools implementing this standard are encouraged to consider adopting [CIP-0129]. Tools that already support [CIP-0129] maintain backward compatibility with the legacy formats specified below but should consider fully transitioning to [CIP-0129] to standardize key formats across the ecosystem. This will help avoid multiple formats and ensure consistency.
 
 This CIP previously also lacked `_vkh` key definitions, which are now added above possible due to the upgrades defined in [CIP-0129]. For detailed information on the new specification and the rationale behind the upgrade, please refer to [CIP-0129].
 
@@ -270,7 +273,6 @@ See [Test Vectors File](./test-vectors.md).
   - [Lace](https://chromewebstore.google.com/detail/lace-sanchonet/djcdfchkaijggdjokfomholkalbffgil?hl=en)
   - [Yoroi](https://chrome.google.com/webstore/detail/yoroi-nightly/poonlenmfdfbjfeeballhiibknlknepo/related)
   - [demos wallet](https://github.com/Ryun1/cip95-demos-wallet)
-  - [CIP-0129]: (https://github.com/cardano-foundation/CIPs/blob/master/CIP-0129/README.md)
 - [ ] The consitutional committee derivation paths are used by two implementations.
 
 ### Implementation Plan
@@ -280,3 +282,6 @@ See [Test Vectors File](./test-vectors.md).
 ## Copyright
 
 This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).
+
+[CIP-0129]: (https://github.com/cardano-foundation/CIPs/blob/master/CIP-0129/README.md)
+[DEPRECATED]: (#deprecated-governance-id-definition)
diff --git a/CIP-0105/test-vectors/test-vector-1.md b/CIP-0105/test-vectors/test-vector-1.md
@@ -42,6 +42,14 @@ Hex: `f74d7ac30513ac1825715fd0196769761fca6e7f69de33d04ef09a0c417a752b1d84110299
 
 Bech32: `drep_xvk17axh4sc9zwkpsft3tlgpjemfwc0u5mnld80r85zw7zdqcst6w543mpq3q2vkjy3nw8x7n8asw4es78dyl4q7u7kwlwn7yy0sugxfrjs6z25qe`
 
+
+#### [DEPRECATED] Verification key hash (DRep ID)
+
+Hex: `a5b45515a3ff8cb7c02ce351834da324eb6dfc41b5779cb5e6b832aa`
+
+Bech32: `drep15k6929drl7xt0spvudgcxndryn4kmlzpk4meed0xhqe25nle07s`
+
+
 #### Verification key hash (DRep VKH)
 
 Hex: `a5b45515a3ff8cb7c02ce351834da324eb6dfc41b5779cb5e6b832aa`

diff --git a/CIP-0105/test-vectors/test-vector-2.md b/CIP-0105/test-vectors/test-vector-2.md
@@ -43,6 +43,14 @@ Hex: `70344fe0329bbacbb33921e945daed181bd66889333eb73f3bb10ad8e4669976a523761cec
 
 Bech32: `drep_xvk1wq6ylcpjnwavhveey855tkhdrqdav6yfxvltw0emky9d3erxn9m22gmkrnkyrqn8922eycuwwqt64q4wds2ssdmlgp5dqq9gem6k5vq23ph3c`
 
+
+#### [DEPRECATED] Verification key hash (DRep ID)
+
+Hex: `1ed314af7d3ff8fcd320c73eb58524d774ca38733ee00ebca81bd63a`
+
+Bech32: `drep1rmf3ftma8lu0e5eqculttpfy6a6v5wrn8msqa09gr0tr5rgcuy9`
+
+
 #### Verification key hash (DRep VKH)
 
 Hex: `1ed314af7d3ff8fcd320c73eb58524d774ca38733ee00ebca81bd63a`

diff --git a/CIP-0105/test-vectors/test-vector-3.md b/CIP-0105/test-vectors/test-vector-3.md
@@ -40,6 +40,14 @@ Hex: `a4a2f459fcc98e7fe0acbea096f4b1fb342cb73aa6c41f62d4d6ca1464179dd65fd61ed957
 
 Bech32: `drep_xvk15j30gk0uex88lc9vh6sfda93lv6zede65mzp7ck56m9pgeqhnht9l4s7m9tad59jmltv3c38nclt942n3feen6ggmhcj6xmmlj6td2qu4ce82`
 
+
+#### [DEPRECATED] Verification key hash (DRep ID)
+
+Hex: `33e587eb1f44e51f4307eeed7ede619008bc4d1c32c18099d6367329`
+
+Bech32: `drep1x0jc06clgnj37sc8amkhahnpjqytcnguxtqcpxwkxeejj4y6sqm`
+
+
 #### Verification key hash (DRep VKH)
 
 Hex: `33e587eb1f44e51f4307eeed7ede619008bc4d1c32c18099d6367329`

diff --git a/CIP-0105/test-vectors/test-vector-4.md b/CIP-0105/test-vectors/test-vector-4.md
@@ -40,6 +40,14 @@ Hex: `ab5d2187f2f4419421b0457f7ac8ab0d4b4ec0802af5de21dde64f603248a381571a0b4d92
 
 Bech32: `drep_xvk14dwjrplj73qeggdsg4lh4j9tp495asyq9t6augwaue8kqvjg5wq4wxstfkf8waakk8pwv8fkrde2cwd47rklfx9xxpn9ulc7nl7sndcvdjh2m`
 
+
+#### [DEPRECATED] Verification key hash (DRep ID)
+
+Hex: `c1a342f0dfb82b93ca2e6b406bacb04802f7d56a99d8f95a80a8b6c5`
+
+Bech32: `drep1cx359uxlhq4e8j3wddqxht9sfqp004t2n8v0jk5q4zmv27sh0h5`
+
+
 #### Verification key hash (DRep VKH)
 
 Hex: `c1a342f0dfb82b93ca2e6b406bacb04802f7d56a99d8f95a80a8b6c5`

diff --git a/CIP-0129/README.md b/CIP-0129/README.md
@@ -15,18 +15,18 @@ License: CC-BY-4.0
 
 ## Abstract
 
-This specification describes the structure and the bech32 format of the identifiers for DRep, CC keys, and Gov Actions
+This Cardano Improvement Proposal (CIP) defines a standardized structure for encoding and representing various governance and credential identifiers, specifically designed for DRep, Constitutional Committee (CC) keys, and Governance Actions within the Conway era. This specification introduces a single-byte header that encapsulates metadata related to the key type and credential type, allowing identifiers to retain critical metadata even when stored as byte arrays. By encoding this metadata directly into the bech32 format, we enhance both usability and interoperability across Cardano infrastructure and tools.
 
 ## Motivation: why is this CIP necessary?
 
-Cardano Conway era introduces new credentials for different actors, and introduces proposal procedures for governance actions. It is required to be able to find, link, share these identifiers in bytes form across the tooling and community.
+The Conway era on Cardano introduces new governance features, requiring unique and identifiable credentials for roles such as DReps, Constitutional Committee members, and distinct governance actions. Existing infrastructure and tools that process bech32 identifiers often decode and store the raw byte data for efficiency, unintentionally stripping away the metadata embedded in the bech32 prefix. This CIP addresses that limitation by embedding metadata into a structured single-byte header, allowing credentials to be stored in byte form without losing essential metadata. This standardization facilitates seamless linkage, sharing, and compatibility of governance identifiers across the ecosystem, supporting a robust and interoperable governance framework in Cardano.
 
 ## Specification
 
 ### Introduction
-We define a bytes representation for the various credentials and identifiers along with the their bech32 prefixes in this CIP. Taking inspiration from the Cardano addresses bytes format, we define an 8 byte header and a payload to define the key, which look similar to the reward address byte form but with a new specification and using the governance credentials.
+We define a bytes representation for the various credentials and identifiers along with the their bech32 prefixes in this CIP. Taking inspiration from the Cardano addresses bytes format, we define an 8 bit header and a payload to define the key, which look similar to the reward address byte format but with a new specification and using the governance credentials.
 
-In this CIP, We also define a simple bech32 prefix for gov actions, which does not have a credential. Gov actions only contain transaction ID bytes and an index, defined in the Gov Action Section below.
+In this CIP, We also define a simple bech32 prefix for gov actions, which does not have a credential. Gov actions only contain transaction ID bytes and an index, defined in the Gov Action Section below. The chosen prefixes for each identifier align with Cardano's established naming convention used in ledger specification, ensuring easy recognition and minimizing confusion within the ecosystem.
 
 ### Binary format
 
@@ -59,7 +59,7 @@ Key Type (`t t t t . . . .`)      | Key
 
 The second half of the header (bits [3;0]) refers to the credential type which can have the values and types as summarized in the table below,
 
-We *reserve* the values 0 and 1, as these are used in the Cardano Address Network tag. By not using these values we will make the gov identifies not become accidentally compatible with a valid address.
+We *reserve* the values 0 and 1 to prevent accidental conflicts with Cardano Address Network tags, ensuring that governance identifiers remain distinct and are not inadvertently processed as addresses.
 
 Credential Type (`. . . . c c c c`)   | Semantic
 ---                                   | ---
@@ -129,7 +129,9 @@ Bech32 - `drep1ygqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq7vlc9n`
 
 ## Rationale: how does this CIP achieve its goals?
 
-By introducing a header and payload design for different keys, we can achieve specifying credentials in a hex format (bytes), being able to share and use across tooling is possible. We also specify bech32 prefixes for user friendly identification of the identifiers.
+This CIP achieves its objectives by introducing a unified header and payload structure for governance-related keys, allowing for metadata to be directly embedded within the byte-level representation of each identifier. By defining a single-byte header that includes both key type and credential type, the proposal provides a consistent, compact format that retains crucial metadata even when stored or transmitted as raw byte arrays. This specification is designed to be forward-compatible, with a capacity to support up to 16 key types, allowing it to evolve with Cardano’s governance and credential requirements.
+
+This approach aligns with existing Cardano address encoding practices while adding specificity for governance keys in the Conway era. By also defining distinct bech32 prefixes for each identifier type, the CIP enhances user-friendliness and makes it easier for tooling and infrastructure to recognize, validate, and link these identifiers within the ecosystem. This design ensures governance identifiers are not only interoperable across platforms but also intuitive and accessible, paving the way for streamlined governance interactions within Cardano’s tooling and community.
 
 
 ## Path to Active
@@ -163,7 +165,7 @@ Tools, Wallets, and Explorers to utilize the identifiers and bech32 prefixes def
 
 - Tools like explorers and wallets - These tools can potentially support both formats to start with for the purpose of allowing users to search for drep, cold keys, hot keys as these 3 are impacted by this CIP upgrade. And can continue to show only this CIP specification, having an easy backward compatibility as well moving to this CIP standard.
 
-- This CIP does not require a hard fork for implementation, the goal is to use the identifies specified in this CIP for the UI, and as a medium of communication for sharing such keys and IDs (though it will be good if this CIP is also enforced at the ledger level, simplifying CDDL and bringing data storage efficiency).
+- This CIP does not require a hard fork for implementation, the goal is to use the identifies specified in this CIP for the UI, and as a medium of communication for sharing such keys and IDs.
 
 ## Copyright