Description
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
- 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