[FEATURE] - extend drep id cmd so that it returns id in hex and bech32 for script based dreps. Use CIP105

[CarlosLopezDeLara]

What

Extend cardano-cli conway drep id so that it returns drep id in hex and bech32 also for script based dreps.

We should use Use CIP105 so that the prefix for script based dreps should be drep_script

EDIT:
Community tools are moving towards CIP129. In particular, the prefix drep_script is deprecated in the latest changes to CIP105. To ensure consistency with other tools we should adopt CIP129.

CIP129 states that:

Binary format
In the header-byte, bits [7;4] indicate the type of gov key being used. The remaining four bits [3;0] are used to define the credential type. There are currently 3 types of credentials defined in the Cardano Conway era, this specification will allow us to define a maximum of 16 different types of keys in the future.

  1 byte     variable length   
 <------> <-------------------> 
┌────────┬─────────────────────┐
│ header │        key      │
└────────┴─────────────────────┘
    🔎                          
    ╎          7 6 5 4 3 2 1 0  
    ╎         ┌─┬─┬─┬─┬─┬─┬─┬─┐ 
    ╰╌╌╌╌╌╌╌╌ |t│t│t│t│c│c│c│c│ 
              └─┴─┴─┴─┴─┴─┴─┴─┘ 

For the case of DReps we have:

Key Type (Role)

Key Type (t t t t . . . .)	Key
0010....	DRep

Credential Type

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,

Credential Type (. . . . c c c c)	Semantic
....0010	Key Hash
....0011	Script Hash

So, for the DRep verification key

{
    "type": "DRepVerificationKey_ed25519",
    "description": "Delegate Representative Verification Key",
    "cborHex": "58208a10253789af22a6493dbe6a3a415732152989a9bd00b010e18f07a7cabcc74a"
}

we get the key-hash with:

cardano-cli conway governance drep id --drep-verification-key-file drep1.vkey --output-format hex
efda35608d806f37ac3948f1ddaff912e5f9130e9b52035c166bd8f2

This credential has Role DRep and type KeyHash, therefore, as per CIP129 we need to add the (binary) header

00100010 

which in hex is:

echo "obase=16; ibase=2; 00100010" | bc
22

Finally, we append the header to the keyhash and serialize as bech32 with drep prefix:

bech32 drep <<< 22efda35608d806f37ac3948f1ddaff912e5f9130e9b52035c166bd8f2
drep1ytha5dtq3kqx7dav89y0rhd0lyfwt7gnp6d4yq6uze4a3us09kg9u

and the round trip

❯ bech32 <<< drep1ytha5dtq3kqx7dav89y0rhd0lyfwt7gnp6d4yq6uze4a3us09kg9u
22efda35608d806f37ac3948f1ddaff912e5f9130e9b52035c166bd8f2

Similarly, for a script based DRep:

❯ cat drep-multisig.json 
{
    "type": "all",
    "scripts": [
      {
        "type": "sig",
        "keyHash": "81af8dbb00d692541de177f794c2c36cc0274c525d4d063820c92ed0"
      },
      {
        "type": "sig",
        "keyHash": "c2bd1035dcb0eddd0f9828e0be14f1d5c76f11bb55f11925da507552"
      }
    ]
  }

❯ cardano-cli hash script --script-file drep-multisig.json 
8f33600845940d65bdbc7ea7a247a7997aa8558649128fa82c4c0468

This credential has Role DRep and type script hash, therefore we add the binary header

00100011`

Convert that to hex, append it to the scriptHash and serialize as bech32 with the drep prefix:

❯ echo "obase=16; ibase=2; 00100011" | bc
23

❯ bech32 drep <<< 238f33600845940d65bdbc7ea7a247a7997aa8558649128fa82c4c0468
drep1yw8nxcqggk2q6edah3l20gj857vh42z4sey39rag93xqg6qytcdp3

and the roundtrip

bech32 <<< drep1yw8nxcqggk2q6edah3l20gj857vh42z4sey39rag93xqg6qytcdp3
238f33600845940d65bdbc7ea7a247a7997aa8558649128fa82c4c0468

This will require modification to cardano-api.

Why

Personas

• DReps
• SPOs
• dApp Devs
• Exchanges
• Wallets
• 3rd party tools
• ADA holders

Definition of Done (DoD)

• Acceptance Criteria + User Stories & DoD created and singed-off (by PO, dev & test owners)
• Builds successfully on CI
• Code & Test review (as per Acceptance Criteria)
• There is documentation and/or examples for the new functionality (usage/response)
• Log/record changes on Vnext (or similar depending on what we adopt)
• Ticket number(s) included in PR description
• All Acceptance Criteria met and covered by dev/unit/property/integration tests
• System/E2E automated tests + System Test Engineer Owner Sign-off

NOTE: Ideally, we should merge only fully implemented and tested features into the master branch.
So all the above steps are required for the PR to be merged.
In order to avoid the PRs becoming stale and requiring to be rebased on master, these can be merged
after a reasonable time (current agreement is 3 days) if the System Test Engineer Owner's sign-off
was not provided (last step in the DoD).

IMPORTANT: Any deviation from the plan should be discussed and agreed as a comment in the Feature file.

Sign-off

• Product Owner
• Dev Owner
• System Test Engineer Owner

Related PRs

1. PR # here

Acceptance Criteria

Acceptance Criteria & User Stories define here (or in a separate file (linked here) for a big feature)

Example - IntersectMBO/cardano-node#4453

[smelc]

@CarlosLopezDeLara> something we can work on together maybe?

[CarlosLopezDeLara]

Wait untill CIP129 or CIP105 is approved.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

[CarlosLopezDeLara]

@smelc I've updated the ticket with the requirements to support CIP129, the original intent has been deprecated by latest changes to CIP105. Still need to wait for CIP129 to move from proposed to active.