diff --git a/.gitignore b/.gitignore deleted file mode 100644 index 82559777ba..0000000000 --- a/.gitignore +++ /dev/null @@ -1,5 +0,0 @@ -/public -/node_modules - -# Mac files -.DS_Store \ No newline at end of file diff --git a/CIP-0005/README.md b/CIP-0005/README.md index b900a97a91..5448ad6ff0 100644 --- a/CIP-0005/README.md +++ b/CIP-0005/README.md @@ -33,58 +33,68 @@ We define the following set of common prefixes with their corresponding semantic ### Keys -| Prefix | Meaning | Contents | -| --- | --- | --- | -| `acct_sk` | CIP-1852's account private key | Ed25519 private key | -| `acct_vk` | CIP-1852's account public key | Ed25519 public key | -| `acct_xsk` | CIP-1852's extended account private key | Ed25519-bip32 extended private key | -| `acct_xvk` | CIP-1852's extended account public key | Ed25519 public key with chain code | -| `acct_shared_sk` | CIP-1854's account private key | Ed25519 private key | -| `acct_shared_vk` | CIP-1854's account public key | Ed25519 public key | -| `acct_shared_xsk` | CIP-1854's extended account private key | Ed25519-bip32 extended private key | -| `acct_shared_xvk` | CIP-1854's extended account public key | Ed25519 public key with chain code | -| `addr_sk` | CIP-1852's address signing key | Ed25519 private key | -| `addr_vk` | CIP-1852's address verification key | Ed25519 public key | -| `addr_xsk` | CIP-1852's address extended signing key | Ed25519-bip32 extended private key | -| `addr_xvk` | CIP-1852's address extended verification key | Ed25519 public key with chain code | -| `addr_shared_sk` | CIP-1854's address signing key | Ed25519 private key | -| `addr_shared_vk` | CIP-1854's address verification key | Ed25519 public key | -| `addr_shared_xsk` | CIP-1854's address extended signing key | Ed25519-bip32 extended private key | -| `addr_shared_xvk` | CIP-1854's address extended verification key | Ed25519 public key with chain code | -| `gov_sk` | Governance vote signing key | Ed25519 private key | -| `gov_vk` | Governance vote verification key | Ed25519 public key | -| `cvote_sk` | CIP-36's vote signing key | Ed25519 private key | -| `cvote_vk` | CIP-36's vote verification key | Ed25519 public key | -| `kes_sk` | KES signing key | KES signing key | -| `kes_vk` | KES verification key | KES verification key | -| `policy_sk` | CIP-1855's policy private key | Ed25519 private key | -| `policy_vk` | CIP-1855's policy public key | Ed25519 public key | -| `pool_sk` | Pool operator signing key | Ed25519 private key | -| `pool_vk` | Pool operator verification key | Ed25519 public key | -| `root_sk` | CIP-1852's root private key | Ed25519 private key | -| `root_vk` | CIP-1852's root public key | Ed25519 public key | -| `root_xsk` | CIP-1852's extended root private key | Ed25519-bip32 extended private key | -| `root_xvk` | CIP-1852's extended root public key | Ed25519 public key with chain code | -| `root_shared_sk` | CIP-1854's root private key | Ed25519 private key | -| `root_shared_vk` | CIP-1854's root public key | Ed25519 public key | -| `root_shared_xsk` | CIP-1854's extended root private key | Ed25519-bip32 extended private key | -| `root_shared_xvk` | CIP-1854's extended root public key | Ed25519 public key with chain code | -| `stake_sk` | CIP-1852's stake address signing key | Ed25519 private key | -| `stake_vk` | CIP-1852's stake address verification key | Ed25519 public key | -| `stake_xsk` | CIP-1852's extended stake address signing key | Ed25519-bip32 extended private key | -| `stake_xvk` | CIP-1852's extended stake address verification key | Ed25519 public key with chain code | -| `stake_shared_sk` | CIP-1854's stake address signing key | Ed25519 private key | -| `stake_shared_vk` | CIP-1854's stake address verification key | Ed25519 public key | -| `stake_shared_xsk` | CIP-1854's extended stake address signing key | Ed25519-bip32 extended private key | -| `stake_shared_xvk` | CIP-1854's extended stake address verification key | Ed25519 public key with chain code | -| `vrf_sk` | VRF signing key | VRF signing key | -| `vrf_vk` | VRF verification key | VRF verification key | +| Prefix | Meaning | Contents | +| --- | --- | --- | +| `acct_sk` | CIP-1852's account private key | Ed25519 private key | +| `acct_vk` | CIP-1852's account public key | Ed25519 public key | +| `acct_xsk` | CIP-1852's extended account private key | Ed25519-bip32 extended private key | +| `acct_xvk` | CIP-1852's extended account public key | Ed25519 public key with chain code | +| `acct_shared_sk` | CIP-1854's account private key | Ed25519 private key | +| `acct_shared_vk` | CIP-1854's account public key | Ed25519 public key | +| `acct_shared_xsk` | CIP-1854's extended account private key | Ed25519-bip32 extended private key | +| `acct_shared_xvk` | CIP-1854's extended account public key | Ed25519 public key with chain code | +| `addr_sk` | CIP-1852's address signing key | Ed25519 private key | +| `addr_vk` | CIP-1852's address verification key | Ed25519 public key | +| `addr_xsk` | CIP-1852's address extended signing key | Ed25519-bip32 extended private key | +| `addr_xvk` | CIP-1852's address extended verification key | Ed25519 public key with chain code | +| `addr_shared_sk` | CIP-1854's address signing key | Ed25519 private key | +| `addr_shared_vk` | CIP-1854's address verification key | Ed25519 public key | +| `addr_shared_xsk` | CIP-1854's address extended signing key | Ed25519-bip32 extended private key | +| `addr_shared_xvk` | CIP-1854's address extended verification key | Ed25519 public key with chain code | +| `cc_cold_sk` | CIP-1852’s constitutional committee cold signing key | Ed25519 private key | +| `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_hot_sk` | CIP-1852’s constitutional committee hot signing key | Ed25519 private key | +| `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 | +| `cvote_sk` | CIP-36's vote signing key | Ed25519 private key | +| `cvote_vk` | CIP-36's vote verification key | Ed25519 public key | +| `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 | +| `kes_sk` | KES signing key | KES signing key | +| `kes_vk` | KES verification key | KES verification key | +| `policy_sk` | CIP-1855's policy private key | Ed25519 private key | +| `policy_vk` | CIP-1855's policy public key | Ed25519 public key | +| `pool_sk` | Pool operator signing key | Ed25519 private key | +| `pool_vk` | Pool operator verification key | Ed25519 public key | +| `root_sk` | CIP-1852's root private key | Ed25519 private key | +| `root_vk` | CIP-1852's root public key | Ed25519 public key | +| `root_xsk` | CIP-1852's extended root private key | Ed25519-bip32 extended private key | +| `root_xvk` | CIP-1852's extended root public key | Ed25519 public key with chain code | +| `root_shared_sk` | CIP-1854's root private key | Ed25519 private key | +| `root_shared_vk` | CIP-1854's root public key | Ed25519 public key | +| `root_shared_xsk` | CIP-1854's extended root private key | Ed25519-bip32 extended private key | +| `root_shared_xvk` | CIP-1854's extended root public key | Ed25519 public key with chain code | +| `stake_sk` | CIP-1852's stake address signing key | Ed25519 private key | +| `stake_vk` | CIP-1852's stake address verification key | Ed25519 public key | +| `stake_xsk` | CIP-1852's extended stake address signing key | Ed25519-bip32 extended private key | +| `stake_xvk` | CIP-1852's extended stake address verification key | Ed25519 public key with chain code | +| `stake_shared_sk` | CIP-1854's stake address signing key | Ed25519 private key | +| `stake_shared_vk` | CIP-1854's stake address verification key | Ed25519 public key | +| `stake_shared_xsk` | CIP-1854's extended stake address signing key | Ed25519-bip32 extended private key | +| `stake_shared_xvk` | CIP-1854's extended stake address verification key | Ed25519 public key with chain code | +| `vrf_sk` | VRF signing key | VRF signing key | +| `vrf_vk` | VRF verification key | VRF verification key | ### Hashes -| Prefix | Meaning | Contents | -| --- | --- | --- | -| `asset` | Fingerprint of a native asset for human comparison | See [CIP-0014] | +| Prefix | Meaning | Contents | +| --- | --- | --- | +| `asset` | Fingerprint of a native asset for human comparison | See [CIP-0014] | | `pool` | Pool operator verification key hash (pool ID) | blake2b\_224 digest of an operator verification key | | `script` | Script hash | blake2b\_224 digest of a serialized transaction script | | `addr_vkh` | Address verification key hash | blake2b\_224 digest of a payment verification key | @@ -99,12 +109,15 @@ We define the following set of common prefixes with their corresponding semantic ### Miscellaneous -| Prefix | Meaning | Contents | -| --- | --- | --- | -| `addr` | Mainnet address | Network tag, payment credential and optional stake credential | -| `addr_test` | Testnet address | Network tag, payment credential and optional stake credential | -| `stake` | Mainnet stake address | Network tag and stake credential | -| `stake_test` | Testnet stake address | Network tag and stake credential | +| Prefix | Meaning | Contents | +| --- | --- | --- | +| `addr` | Mainnet address | Network tag, payment credential and optional stake credential | +| `addr_test` | Testnet address | Network tag, payment credential and optional stake credential | +| `cc_cold` | Constitutional committee cold credential | committee cold credential | +| `cc_hot` | Constitutional committee hot credential | committee hot credential | +| `drep` | DRep credential | DRep credential | +| `stake` | Mainnet stake address | Network tag and stake credential | +| `stake_test` | Testnet stake address | Network tag and stake credential | ## Rationale: how does this CIP achieve its goals? diff --git a/CIP-0010/registry.json b/CIP-0010/registry.json index b6a975b69b..5cbe3a7dcb 100644 --- a/CIP-0010/registry.json +++ b/CIP-0010/registry.json @@ -55,6 +55,10 @@ "transaction_metadatum_label": 1888, "description": "amphitheatre by the ape society" }, + { + "transaction_metadatum_label": 1904, + "description": "Proof of origin and quality related verification data in supply chain" + }, { "transaction_metadatum_label": 1967, "description": "nut.link metadata oracles registry" diff --git a/CIP-0072/README.md b/CIP-0072/README.md index 709e1dd497..ad32d2d51c 100644 --- a/CIP-0072/README.md +++ b/CIP-0072/README.md @@ -6,6 +6,7 @@ Category: Metadata Authors: - Bruno Martins - Mateusz Czeladka + - Daniel Main Implementors: ["Lace Wallet dApp Store", "DappsOnCardano dApp Store"] Discussions: - https://github.com/cardano-foundation/CIPs/pull/355 @@ -49,26 +50,21 @@ Stores and auditors should be able to follow the chain and find when a new dApp - **`integrity`**: The dApp's off-chain metadata should match the metadata **anchored** on-chain. - **`trust`**: The dApp's certificate should be signed by a trusted entity. It's up to the store/auditor to decide which entities are trusted and they should maintain and publish their own list of trusted entities. Although this entities might be well known, it's not the responsibility of this CIP to maintain this list. These entities could be directly associated with developer/publisher or not. -### **On-chain dApp Registration Certificate** - -The on-chain dApp registration certificate MUST follow canonical JSON and be serialised according to RFC 8785 (https://www.rfc-editor.org/rfc/rfc8785). This stipulation is to avoid any ambigiutines in the signature calculation. +### **On-chain dApp Registration** ```json { "subject": "b37aabd81024c043f53a069c91e51a5b52e4ea399ae17ee1fe3cb9c44db707eb", "rootHash": "7abcda7de6d883e7570118c1ccc8ee2e911f2e628a41ab0685ffee15f39bba96", "metadata": [ - "https://foundation.app/my_dapp_7abcda.json" + "https://foundation.app/my_dapp_7abcda/tart/", + "7abcda7de6d883e7570118c1ccc8ee2e91", + "e4ea399ae17ee1fe3cb9c44db707eb/", + "offchain.json" ], "type": { "action": "REGISTER", "comment": "New release adding zapping support." - }, - "signature": { - "r": "27159ce7d992c98fb04d5e9a59e43e75f77882b676fc6b2ccb8e952c2373da3e", - "s": "16b59ab1a9e349cd68d232f7652f238926dc24a2e435949ebe2e402a6557cfb4", - "algo": "Ed25519−EdDSA", - "pub": "b384b53d5fe9f499ecf088083e505f40d2a6c123bf7201608494fdb89a051b80" } } ``` @@ -83,19 +79,17 @@ The on-chain dApp registration certificate MUST follow canonical JSON and be ser - *`REGISTER`*: The certificate is asserting that the dApp is registered for the first time or is providing an update. - *`DE_REGISTER`*: The certificate is asserting that the dApp is deprecated / archived. So, no further dApp's on-chain update is expected. -*`rootHash`*: The hash of the entire offchain metadata tree object. This hash is used by clients to verify the integrity of the metadata tree object. When reading a metadata tree object, the client should calculate the hash of the object and compare it with the `rootHash` property. If the two hashes don't match, the client should discard the object. The metadata tree object is a JSON object that contains the dApp's metadata. The metadata tree object is described in the next section. Please note that off-chain JSON must be converted into RFC 8765 canonical form before taking the hash! - -*`metadata`*: An array of links to the dApp's metadata. The metadata is a JSON compatible RFC 8785 object that contains the dApp's metadata. +*`rootHash`*: The blake2b-256 hash of the entire offchain metadata tree object. This hash is used by clients to verify the integrity of the metadata tree object. When reading a metadata tree object, the client should calculate the hash of the object and compare it with the `rootHash` property. If the two hashes don't match, the client should discard the object. The metadata tree object is a JSON object that contains the dApp's metadata. The metadata tree object is described in the next section. Please note that off-chain JSON must be converted into RFC 8765 canonical form before taking the hash! -*`signature`*: The signature of the certificate. The publishers generate the signature is by first turning on-chain JSON into a canonical form (RFC 8765), hashing it with blake2b-256 and generating a signature of the hash. Stores / clients can verify the signature by repeating the process, they can use the public key to verify the signature of the certificate. Fields used for canonical JSON: ["subject", "rootHash", "metadata","type"]. Please note that a signature should be generated of blake2b-256 hash as a byte array, not as a hex represented string(!). +*`metadata`*: Chunks of URLs that make up the dApp's metadata are arranged in an array to accommodate the 64-character limit per chunk, allowing for the support of longer URLs. The metadata itself is a JSON object compatible with RFC 8785, containing detailed information about the dApp ### On-chain Schemas -[On-chain CDDL for registration / de-registration (Version 1)](./version_1_onchain.cddl) +[On-chain CDDL for registration / de-registration (Version 2.0.0)](./version_2.0.0_onchain.cddl) which also can be expressed using JSON schema: -[dApp on-chain certificate JSON Schema (Version 1)](./version_1_onchain.json) +[dApp on-chain certificate JSON Schema (Version 2.0.0)](./version_2.0.0_onchain.json) ### Metadata Label @@ -107,51 +101,65 @@ When submitting the transaction metadata pick the following value for `transacti The dApp Registration certificate itself doesn't enforce a particular structure to the metadata you might fetch off-chain. However, we recommend that you use the following structure: -[Off-chain dApp Registration certificate schema (Version 1)](./version_1_offchain.json) +[Off-chain dApp Registration certificate schema (Version 2)](./version_2.0.0_offchain.json) -This schema describes the minimum required fields for a store to be able to display and validate your dApp. You can add any other fields you want to the metadata, but we recommend that you use at least the ones described above. +This schema describes the minimum required fields for a store to be able to display and validate your dApp. ### Example ```json { - "subject": "9SYAJPNN", - "projectName": "My Project", - "link": "https://myProject.app", - "logo": "https://myProject.app/logo.png", - "social": { - "github": "https://mywebsite.com", - "twitter": "https://twitter.com/my_dapp", - "website": "https://github.com/my_dapp" - }, - "categories": ["Games"], + "version": "1.0.0", + "subject": "abcdef1234567890", + "projectName": "My dApp", + "link": "https://www.exampledapp.com", + "companyName": "Amazing dApp Inc.", + "companyEmail": "contact@myamazingdapp.com", + "companyWebsite": "https://www.myamazingdapp.com", + "logo": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAUAAA...", + "categories": ["DeFi", "Games"], + "screenshots": [ + "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD...", + "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD..." + ], + "social": [ + { + "name": "GitHub", + "link": "https://github.com/exampledapp" + }, + { + "name": "Twitter", + "link": "https://twitter.com/exampledapp" + } + ], "description": { - "short": "A story rich game where choices matter. This game is very addictive to play :)" + "short": "This is a short description of the dApp, giving an overview of its features and capabilities." }, "releases": [ { "releaseNumber": "1.0.0", - "releaseName": "V1", + "releaseName": "Initial Release", + "securityVulnerability": false, + "comment": "First major release with all core features.", "scripts": [ { - "id": "PmNd6w", - "version": 1 + "id": "script1", + "version": "1.0.0" } ] } ], "scripts": [ { - "id": "PmNd6w", - "name": "marketplace", - "purposes": ["SPEND"], + "id": "script1", + "name": "Example Script", + "purposes": ["SPEND", "MINT"], "type": "PLUTUS", "versions": [ { - "version": 1, + "version": "1.0.0", "plutusVersion": 1, - "scriptHash": "711dcb4e80d7cd0ed384da5375661cb1e074e7feebd73eea236cd68192", - "contractAddress": "addr1wywukn5q6lxsa5uymffh2esuk8s8fel7a0tna63rdntgrysv0f3ms" + "scriptHash": "abc123" } ] } @@ -205,9 +213,9 @@ Release Name is a field, which dApp developers can use on top of Release Version At the begining neither on-chain, nor off-chain JSON has been following RFC 8785 (canonical JSON) but we reached a point that, due to consistency checks, we need to take hash of both on-chain and off-chain and this forced us to stipulate that both on-chain and off-chain metadata documents need to be converted according to RFC 8785 before taking a blake2b-256 hash of them. -### On-Chain Signature Scope +### Transaction Signature Scope -On-chain part has a signature, which has a role to verify that a certain dApp owner made changes. In the initial version, a blake2b-256 signature was needed only for `rootHash` but following discussion, due to security concerns, decision has been made that the signature should attest the whole on-chain canonical JSON except signature field itself (because it would end up in an infinite recursion). +As any transaction in cardano network has a signature, which has a role to verify that a certain dApp owner made changes. ### Who Is The Owner? @@ -255,10 +263,6 @@ some app that can attest validity and conformance to JSON schema - dApp Registra We made a decision to change the schema so that scripts and releases are no longer required. This could help to get initial registration from dApp developers faster and some stores simply do not require dApps to add their scripts in order to be listed. -### Schema Version - -We discussed and analyzed idea of schema version and or even whole CIP version. It turns out that CIP is already versioned by CIP-??? where ??? is version number. During this CIP being in `PROPOSED` state we reserve our right to make small changes to the schema / document, after CIP becomes active, it will require a new CIP. This is the current process, which other CIPs are also following. - ### Tags We briefly discussed tags and we will likely introduce tags in the future. An array of tags to help stores / dApp developers categories where their dApp should show. This will complement `categories` field. diff --git a/CIP-0072/version_1_onchain.json b/CIP-0072/version_1_onchain.json deleted file mode 100644 index ef9bf510d6..0000000000 --- a/CIP-0072/version_1_onchain.json +++ /dev/null @@ -1,105 +0,0 @@ -{ - "$schema":"https://json-schema.org/draft/2020-12/schema", - "$id":"https://example.com/dApp.schema.json", - "title": "Cardano dApp Claim", - "description": "Registration of Cardano dApp claim.", - "type":"object", - "properties":{ - "subject":{ - "type":"string", - "minLength": 1, - "maxLength": 64, - "pattern":"^[0-9a-fA-F]{1,64}$", - "description":"Identifier of the claim subject (dApp). A UTF-8 encoded string, must be max 64 chars. Typically it is randomly generated hash by the dApp developer." - }, - "rootHash":{ - "type":"string", - "minLength": 64, - "maxLength": 64, - "pattern":"^[0-9a-fA-F]{64}$", - "description":"blake2b-256 hash of the metadata describing the off-chain part of the dApp." - }, - "metadata": { - "type": "array", - "description": "An array of valid URLs pointing to off-chain CIP-72 compatible metadata document. If an individual URL is longer than 64 characters, it must be expressed as an array of strings (where each string may contain at most 64 characters).", - "items": { - "anyOf": [{ - "type": "string", - "minLength": 1, - "maxLength": 64 - }, { - "type": "array", - "items": { - "type": "string", - "minLength": 1, - "maxLength": 64 - } - }], - "examples": ["https://raw.githubusercontent.com/org/repo/offchain.json", ["https://raw.githubusercontent.com/long-org-name/", "long-repo-name/offchain.json"], "ipfs://QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp", ["ipfs://QmbQDvKJeo2NgGcGdnUiaAdADA", "UFibTzuKNKc0jA390alDAD5Uij7jzmK8ZccmWp"]] - } - }, - "type":{ - "type":"object", - "description":"Describes the releases, if they are new or an updates.", - "properties":{ - "action":{ - "type":"string", - "enum":["REGISTER", "DE_REGISTER"], - "description":"Describes the action this certificate is claiming; i.e 'REGISTER', for a new dApp or an update, DE_REGISTER for asserting that the dApp's development is stopped, and it is deprecated. So, no further dApp's on-chain update is to be expected." - }, - "comment": { - "type": "string", - "minLength": 1, - "maxLength": 64, - "description": "A free text field to provide details about this particular changes (64 chars limited)." - } - }, - "required":[ - "action" - ] - }, - "signature":{ - "description":"Signature of the blake2b-256 hash of whole canonical (RFC 8785) JSON document (except signature property).", - "type":"object", - "properties":{ - "r":{ - "type":"string", - "description":"A hex representation of the R component of the signature.", - "minLength": 64, - "maxLength": 64, - "pattern":"^[0-9a-fA-F]{64}$" - }, - "s":{ - "type":"string", - "description":"A hex representation of the S component of the signature.", - "minLength": 64, - "maxLength": 64, - "pattern":"^[0-9a-fA-F]{64}$" - }, - "algo":{ - "const":"Ed25519-EdDSA" - }, - "pub":{ - "type":"string", - "description":"A hex representation of the public key.", - "minLength": 64, - "maxLength": 64, - "pattern":"^[0-9a-fA-F]{64}$" - } - }, - "required":[ - "r", - "s", - "algo", - "pub" - ] - } - }, - "required":[ - "subject", - "rootHash", - "type", - "signature" - ] - } - \ No newline at end of file diff --git a/CIP-0072/version_1_offchain.json b/CIP-0072/version_2.0.0_offchain.json similarity index 55% rename from CIP-0072/version_1_offchain.json rename to CIP-0072/version_2.0.0_offchain.json index d1e8b306df..2870670aa0 100644 --- a/CIP-0072/version_1_offchain.json +++ b/CIP-0072/version_2.0.0_offchain.json @@ -2,6 +2,11 @@ "$schema": "https://json-schema.org/draft/2020-12/schema", "type":"object", "properties": { + "version": { + "type": "string", + "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?(?:\\+([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?$", + "description": "Off-chain schema version following Semantic Versioning" + }, "subject": { "type":"string", "minLength": 1, @@ -11,69 +16,115 @@ }, "projectName": { "type":"string", - "description": "A project name, e.g. My dApp." + "description": "A project name, e.g. My dApp.", + "maxLength": 40 }, "link": { "type":"string", - "description": "Website presenting a dApp.", - "pattern": "(https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|www\\.[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9]+\\.[^\\s]{2,}|www\\.[a-zA-Z0-9]+\\.[^\\s]{2,})" - }, - "logo": { + "description": "A link a dApp or a website presenting a DApp", + "pattern": "((https?|ipfs|ipns):\/\/[\\u00C0-\\u017F-a-zA-Z0-9])", + "maxLength": 200 + }, + "companyName": { + "type":"string", + "description": "Company name", + "maxLength": 100 + }, + "companyEmail": { + "type":"string", + "description": "Contact email of the company behind the dApp", + "pattern": "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$", + "maxLength": 200 + }, + "companyWebsite": { "type":"string", - "description": "URL to the logo or the base64 encoded image." + "description": "Website of the company behind the dApp.", + "pattern": "((https?|ipfs|ipns):\/\/[\\u00C0-\\u017F-a-zA-Z0-9])", + "maxLength": 200 + }, + "logo": { + "description": "Logo encoded in base64. Minimum resolution: 512x512px, supported formats: PNG/JPG/SVG, maximum file size: 1 MB", + "type": "string", + "contentEncoding": "base64", + "oneOf": [ + { + "contentMediaType": "image/png" + }, + { + "contentMediaType": "image/jpeg" + }, + { + "contentMediaType": "image/svg+xml" + } + ], + "maxLength": 1361000 }, "categories": { "type":"array", "items": { "type": "string", - "enum":["Games", "DeFi", "Gambling", "Exchanges", "Collectibles", "Marketplaces", "Social", "Other"] + "enum": ["DeFi", "Development", "Education", "Games", "Identity", "Marketplace", "NFT", "Other", "Security"] }, "description": "One or more categories. Category MUST be one of the following schema definition." }, + "screenshots": { + "type": "array", + "maxItems": 10, + "items": { + "description": "Screenshots encoded in base64. Minimum resolution for base64 images: 1920x1080px, supported formats: PNG/JPG/SVG, maximum file size: 2 MB for base64.", + "type": "string", + "contentEncoding": "base64", + "oneOf": [ + { + "contentMediaType": "image/png" + }, + { + "contentMediaType": "image/jpeg" + }, + { + "contentMediaType": "image/svg+xml" + } + ], + "maxLength": 2722000 + }, + "description": "Screenshots of the DApp encoded in base64. We recommend to share screenshots from the dApp usage itself." + }, "social": { - "type":"object", - "properties": { - "website": { - "type":"string", - "description": "dApps website link.", - "pattern": "(https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|www\\.[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9]+\\.[^\\s]{2,}|www\\.[a-zA-Z0-9]+\\.[^\\s]{2,})" - }, - "twitter": { - "type":"string", - "description": "An optional Twitter link.", - "pattern": "(https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|www\\.[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9]+\\.[^\\s]{2,}|www\\.[a-zA-Z0-9]+\\.[^\\s]{2,})" - }, - "github": { - "type":"string", - "description": "An optional Github link.", - "pattern": "(https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|www\\.[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9]+\\.[^\\s]{2,}|www\\.[a-zA-Z0-9]+\\.[^\\s]{2,})" - }, - "discord": { - "type":"string", - "description": "An optional Discord link.", - "pattern": "(https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|www\\.[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\\.[^\\s]{2,}|https?:\/\/(?:www\\.|(?!www))[a-zA-Z0-9]+\\.[^\\s]{2,}|www\\.[a-zA-Z0-9]+\\.[^\\s]{2,})" + "type": "array", + "items": { + "type": "object", + "properties": { + "name": { + "type": "string", + "description": "The platform or resource identifier (GitHub, Website, X.com, etc)" + }, + "link": { + "type": "string", + "pattern": "((https?|ipfs|ipns):\/\/[\\u00C0-\\u017F-a-zA-Z0-9])", + "maxLength": 200 + } } - }, - "required": ["website"] + } }, "description": { "type": "object", "properties": { "short": { "type": "string", - "description": "Short dApp description (no less than 40 and no longer than 168 characters).", + "description": "Short dApp description.", "minLength": 40, "maxLength": 168 }, "long": { "type": "string", - "description": "An optional long dApp description (no less than 40 and no longer than 1008 characters).", + "description": "An optional long dApp description.", "minLength": 40, "maxLength": 1008 } }, "required": [ - "short" + "short", + "long" ] }, "releases": { @@ -84,8 +135,8 @@ "properties": { "releaseNumber": { "type": "string", - "pattern": "^(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-((0|[1-9][0-9]*|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*)(\\.(0|[1-9][0-9]*|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*))*))?(\\+([0-9a-zA-Z-]+(\\.[0-9a-zA-Z-]+)*))?$", - "description": "Semver compatible release number (major.minor.patch) or (major.minor.patch-some_text) e.g. 1.2.3 or 1.1.1-alpha" + "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?(?:\\+([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?$", + "description": "Semver compatible release number (major.minor.patch)" }, "releaseName": { "type": "string", @@ -109,7 +160,8 @@ "type": "string" }, "version": { - "type": "integer" + "type": "string", + "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?(?:\\+([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?$" } }, "required": [ @@ -143,8 +195,8 @@ "purposes":{ "type":"array", "items": { - "type": "string", - "enum":["SPEND", "MINT"] + "type": "string", + "enum":["SPEND", "MINT"] }, "description": "Purpouses of the script, SPEND or MINT (notice it can be both for some modern Cardano languages)." }, @@ -158,9 +210,10 @@ { "type":"object", "properties":{ - "version":{ - "type":"integer", - "description":"Script version, monotonically increasing." + "version": { + "type": "string", + "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?(?:\\+([0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*))?$", + "description": "Script version following Semantic Versioning" }, "plutusVersion":{ "type":"integer", @@ -199,9 +252,15 @@ "subject", "projectName", "link", + "companyName", + "companyEmail", + "companyWebsite", "social", + "logo", "categories", - "description" - ] - } - \ No newline at end of file + "screenshots", + "description", + "version" + ], + "additionalProperties": false +} diff --git a/CIP-0072/version_1_onchain.cddl b/CIP-0072/version_2.0.0_onchain.cddl similarity index 79% rename from CIP-0072/version_1_onchain.cddl rename to CIP-0072/version_2.0.0_onchain.cddl index f605418180..9219871a5a 100644 --- a/CIP-0072/version_1_onchain.cddl +++ b/CIP-0072/version_2.0.0_onchain.cddl @@ -11,7 +11,6 @@ on-chain_metadata = { rootHash: sig_256, metadata: [+ string] / [+ string / [+ string]], type: registration / de-registration, - signature: signature, } registration = { @@ -22,11 +21,4 @@ registration = { de-registration = { action: "DE_REGISTER", ? comment: string, -} - -signature = { - r: string, - s: string, - algo: text .regexp "Ed25519-EdDSA", - pub: string, -} +} \ No newline at end of file diff --git a/CIP-0072/version_2.0.0_onchain.json b/CIP-0072/version_2.0.0_onchain.json new file mode 100644 index 0000000000..0942715c14 --- /dev/null +++ b/CIP-0072/version_2.0.0_onchain.json @@ -0,0 +1,59 @@ +{ + "$schema":"https://json-schema.org/draft/2020-12/schema", + "$id":"https://example.com/dApp.schema.json", + "title": "Cardano dApp Claim", + "description": "Registration of Cardano dApp claim.", + "type":"object", + "properties":{ + "subject":{ + "type":"string", + "minLength": 1, + "maxLength": 64, + "pattern":"^[0-9a-fA-F]{1,64}$", + "description":"Identifier of the claim subject (dApp). A UTF-8 encoded string, must be max 64 chars. Typically it is randomly generated hash by the dApp developer." + }, + "rootHash":{ + "type":"string", + "minLength": 64, + "maxLength": 64, + "pattern":"^[0-9a-fA-F]{64}$", + "description":"blake2b-256 hash of the metadata describing the off-chain part of the dApp." + }, + "metadata": { + "type": "array", + "description": "Chunks of URLs that make up the dApp's metadata (pointing to off-chain CIP-72) are arranged in an array to accommodate the 64-character limit per chunk, allowing for the support of longer URLs", + "items": { + "type": "string", + "minLength": 1, + "maxLength": 64 + } + }, + "type":{ + "type":"object", + "description":"Describes the releases, if they are new or an updates.", + "properties":{ + "action":{ + "type":"string", + "enum":["REGISTER", "DE_REGISTER"], + "description":"Describes the action this certificate is claiming; i.e 'REGISTER', for a new dApp or an update, DE_REGISTER for asserting that the dApp's development is stopped, and it is deprecated. So, no further dApp's on-chain update is to be expected." + }, + "comment": { + "type": "string", + "minLength": 1, + "maxLength": 64, + "description": "A free text field to provide details about this particular changes (64 chars limited)." + } + }, + "required":[ + "action" + ] + } + }, + "required":[ + "subject", + "rootHash", + "type" + ], + "additionalProperties": false +} + \ No newline at end of file diff --git a/CIP-0095/README.md b/CIP-0095/README.md index b53fef7583..01b62583af 100644 --- a/CIP-0095/README.md +++ b/CIP-0095/README.md @@ -89,62 +89,6 @@ connector, this specification could be applied to similar standards. > **Note** This specification will evolve as the proposed ledger governance > model matures. -### DRep Key - -⚠ These definitions are an initial version of these keys, such definitions are -to be moved to a new CIP. Once new CIP is published please view that CIP. - -The Conway ledger era introduces a new _first class_ credential in -[`drep_credential`](https://github.com/input-output-hk/cardano-ledger/blob/1beddd3d9f10d8fcb163b5e83985c4bac6b74be7/eras/conway/test-suite/cddl-files/conway.cddl#L332). -This is used to identify registered DReps on-chain, via their certificates and -votes. - -Here we introduction of DRep Keys to be used to create `drep_credential`s for -(non-script) registered DReps. - -#### Derivation - -Here we describe DRep Key derivation as it attains to Cardano wallets who follow -the -[CIP-1852 | HD (Hierarchy for Deterministic) Wallets for Cardano](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md) -standard. - -To differentiate DRep keys from other Cardano keys the derivation path must -follow: - -`m / 1852' / 1815' / account' / 3 / address_index` - -We strongly suggest that a maximum of one set of DRep keys should be associated -with one wallet account, this can be achieved by only ever setting -`address_index=0`. This avoids the need for DRep Key discovery. - -We believe the overhead that would be introduced by "multi-DRep" accounts is an -unjustified expense. Future iterations of this specification may expand on this, -but at present this is seen as unnecessary. - -#### Tooling - -Supporting tooling should clearly label these key pairs as "CIP-95 DRep Keys". - -Bech32 prefixes of `drep_sk` and `drep_vk` should be used, as described in -[CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md). - -Examples of acceptable `keyType`s for supporting tools: - -| `keyType` | Description | -| ------------------------------------------- | --------------------- | -| `DRepSigningKey_ed25519` | DRep Signing Key | -| `DRepExtendedSigningKey_ed25519_bip32` | DRep Signing Key | -| `DRepVerificationKey_ed25519` | DRep Verification Key | -| `DRepExtendedVerificationKey_ed25519_bip32` | DRep Verification Key | - -For hardware implementations: - -| `keyType` | Description | -| ----------------------------- | ------------------------------ | -| `DRepVerificationKey_ed25519` | Hardware DRep Verification Key | -| `DRepHWSigningFile_ed25519` | Hardware DRep Signing File | - ### Data Types #### CIP-30 Inherited Data Types @@ -213,7 +157,7 @@ type PubDRepKey = string; ``` A hex-encoded string representing 32 byte Ed25519 DRep public key, as described -in [DRep Key](#DRep-key). +in [CIP-0105 | Conway Era Key Chains for HD Wallets](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md). ##### PubStakeKey @@ -330,7 +274,7 @@ extension object, as part of the extensions object passed at enable time: #### `api.cip95.getPubDRepKey(): Promise` The connected wallet account provides the account's public DRep Key, derivation -as described in [DRep Key](#DRep-key). +as described in [CIP-0105](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md). These are used by the client to identify the user's on-chain CIP-1694 interactions, i.e. if a user has registered to be a DRep. @@ -886,50 +830,6 @@ implementations to support Conway artifacts to `.signData()` and `.signTx()`. But if so they must support the CIP-95 object flag at connection time, so that clients are aware of this functionality. -### DRep Key - -// todo: move to DRep Key CIP - -We chose to introduce the concept of a DRep Key, building on top of CIP-1694, -this we see as a necessary step for wallet implementors. By setting a -(hierarchical) deterministic derivation path it enables restorability from a -seed phrase. - -With this definition we aim to standard for all ecosystem tooling to be able to -derive DRep credentials from mnemonics. This brings the benefits ecosystem -standards. - -#### Derivation Path - -When choosing the derivation path there were a few possible options. Initially -we chose to follow how a new key definition was done in -[CIP-36](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0036/README.md#derivation-path) -by defining a new purpose of `1718'`. This was an oversight, as defining a new -derivation purposes will likely have hardware wallet audit implications. - -#### Why not reuse [CIP-36 Vote Keys](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0036/README.md#voting-key)? - -CIP-36 defines derivation path for a key pair to be used within CIP-36 style -governance. The most notable user of this standard is -[Project Catalyst](https://projectcatalyst.io), where CIP-36 vote keys are used to sign -vote transactions for the Jormungandr side-chain. - -One suggestion is to reuse this key pair instead of defining a new key pair in -DRep key. The benefits to this would be that it is easier for users and tools to -manage a single key pair to be used for any projects following the CIP-36 -standard and for use in this API. This would mean a single key could be used to -sign Catalyst votes and CIP-1694 DRep votes. - -Reusing keys comes with the downside of possible confusion for users and -tooling. This is why we have attempted to assign the DRep keys clear and -explicit naming and usage to avoid confusion with CIP-36 vote keys. Furthermore, -the keys described here are used for more than just vote signing just the -"CIP-36 vote key" naming may be a cause of confusion. - -> **Note** The derivation path used for CIP-36 vote keys includes `1694` as the -> `purpose`, this is a perhaps misleading reality and hints to the original -> intension of using CIP-36 vote keys for Cardano's Voltaire. - ### Multi-stake Key Support Although diff --git a/CIP-0105/README.md b/CIP-0105/README.md new file mode 100644 index 0000000000..cff75582f4 --- /dev/null +++ b/CIP-0105/README.md @@ -0,0 +1,248 @@ +--- +CIP: 105 +Title: Conway Era Key Chains for HD Wallets +Status: Proposed +Authors: + - Ryan Williams +Implementors: [] +Discussions: + - https://github.com/cardano-foundation/cips/pulls/597 +Created: 2023-09-22 +License: CC-BY-4.0 +--- + +## Abstract + +The Conway Ledger era introduces many new features to Cardano, notably features to support community governance via CIP-1694. +This includes the introduction of the new first class credentials; `drep_credential`, `committee_cold_credential` and `committee_hot_credential`. + +We propose a HD wallet key derivation paths for registered DReps and constitutional committee members to deterministically derive keys from which credentials can be generated. +Such keys are to be known as DRep keys, constitutional committee cold keys and constitutional committee hot keys. +Here we define some accompanying tooling standards. + +> **Note** this proposal assumes knowledge of the Conway ledger design (see +> [draft ledger specification](https://github.com/input-output-hk/cardano-ledger/blob/d2d37f706b93ae9c63bff0ff3825d349d0bd15df/eras/conway/impl/cddl-files/conway.cddl)) +> and +> [CIP-1694](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md). + +## Motivation: why is this CIP necessary? + +In the Conway ledger era, DRep credentials allow registered DReps to be identified on-chain, in DRep registrations, retirements, votes, and in vote delegations from ada holders. +Whilst constitutional committee members can be recognized by their cold credentials within update committee governance actions, authorize hot credential certificate and resign cold key certificates. +Constitutional committee hot credential can be observed within the authorize hot key certificate and votes. + +CIP-1694 terms these DRep credentials as DRep IDs, which are either generated from blake2b-224 hash digests of Ed25519 public keys owned by the DRep, or are script hash-based. +Similarly, both the hot and cold credentials for constitutional committee members can be generated from public key digests or script hashes. + +This CIP defines a standard way for wallets to derive DRep and constitutional committee keys. + +Since it is best practice to use a single cryptographic key for a single purpose, we opt to keep DRep and committee keys separate from other keys in Cardano. + +By adding three paths to the [CIP-1852 | HD (Hierarchy for Deterministic) Wallets for Cardano](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md), we create an ecosystem standard for wallets to be able to derive DRep and constitutional committee keys. +This enables DRep and constitutional committee credential restorability from a wallet seed phrase. + +Stakeholders for this proposal are wallets that follow the CIP-1852 standard and tool makers wishing to support DReps and or constitutional committee members. +This standard allows DReps and constitutional committee members to use alternative wallets whilst being able to be correctly identified. +By defining tooling standards, we enable greater interoperability between governance-focussed tools. + +## Specification + +### Derivation + +#### DRep Keys + +Here we describe DRep key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard. + +To differentiate DRep keys from other Cardano keys, we define a new `role` index of `3`: + +`m / 1852' / 1815' / account' / 3 / address_index` + +We strongly recommend that a maximum of one set of DRep keys should be associated with one wallet account, which can be achieved by setting `address_index=0`. + +#### DRep ID + +Tools and wallets can generate a DRep ID (`drep_credential`) from the Ed25519 public DRep key (without chaincode) by creating a blake2b-224 hash digest of the key. +As this is key-based credential it should be marked as entry `0` in a credential array. + +#### Constitutional Committee Cold Keys + +Here we describe constitutional committee cold key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard. + +To differentiate constitutional committee cold keys from other Cardano keys, we define a new `role` index of `4`: + +`m / 1852' / 1815' / account' / 4 / address_index` + +We strongly recommend that a maximum of one set of constitutional committee cold keys should be associated with one wallet account, which can be achieved by setting `address_index=0`. + +#### Constitutional Committee Cold Credential + +Tools and wallets can generate a constitutional committee cold credential (`committee_cold_credential`) from the Ed25519 public constitutional committee cold key (without chaincode) by creating a blake2b-224 hash digest of the key. +As this is key-based credential it should be marked as entry `0` in a credential array. + +#### Constitutional Committee Hot Keys + +Here we describe constitutional committee hot key derivation as it pertains to Cardano wallets that follow the CIP-1852 standard. + +To differentiate constitutional committee hot keys from other Cardano keys, we define a new `role` index of `5`: + +`m / 1852' / 1815' / account' / 5 / address_index` + +We strongly recommend that a maximum of one set of constitutional committee hot keys should be associated with one wallet account, which can be achieved by setting `address_index=0`. + +#### Constitutional Committee Hot Credential + +Tools and wallets can generate a constitutional committee hot credential (`committee_hot_credential`) from the Ed25519 public constitutional committee hot key (without chaincode) by creating a blake2b-224 hash digest of the key. +As this is key-based credential it should be marked as entry `0` in a credential array. + +### Bech32 Encoding + +These are also described in [CIP-0005 | Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md), but we include them here for completeness. + +#### DRep Keys + +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` | DRep credential | DRep credential | + +#### Constitutional Committee Cold Keys + +Constitutional cold keys and credential should be encoded in Bech32 with the following prefixes: + +| Prefix | Meaning | Contents | +| ------------- | --------------------------------------------------------------------- | ---------------------------------- | +| `cc_cold_sk` | CIP-1852’s constitutional committee cold signing key | Ed25519 private key | +| `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` | Constitutional committee cold credential | committee cold credential | + +#### Constitutional Committee Hot Keys + +Constitutional hot keys and credential should be encoded in Bech32 with the following prefixes: + +| Prefix | Meaning | Contents | +| ------------ | --------------------------------------------------------------------- | ---------------------------------- | +| `cc_hot_sk` | CIP-1852’s constitutional committee hot signing key | Ed25519 private key | +| `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` | Constitutional committee hot credential | committee hot credential | + +### Tooling Definitions + +### DRep Keys + +Supporting tooling should clearly label these key pairs as "DRep Keys". + +Examples of acceptable `keyType`s for supporting tools: + +| `keyType` | Description | +| ------------------------------------------- | ------------------------------ | +| `DRepSigningKey_ed25519` | DRep Signing Key | +| `DRepExtendedSigningKey_ed25519_bip32` | DRep Extended Signing Key | +| `DRepVerificationKey_ed25519` | DRep Verification Key | +| `DRepExtendedVerificationKey_ed25519_bip32` | DRep Extended Verification Key | + +For hardware implementations: + +| `keyType` | Description | +| ----------------------------- | ------------------------------ | +| `DRepHWSigningFile_ed25519` | Hardware DRep Signing File | +| `DRepVerificationKey_ed25519` | Hardware DRep Verification Key | + +#### Constitutional Committee Cold Keys + +Supporting tooling should clearly label these key pairs as "Constitutional Committee Cold Keys". + +Examples of acceptable `keyType`s for supporting tools: + +| `keyType` | Description | +| ------------------------------------------------------------------ | ------------------------------------------------------- | +| `ConstitutionalCommitteeColdSigningKey_ed25519` | Constitutional Committee Cold Signing Key | +| `ConstitutionalCommitteeColdExtendedSigningKey_ed25519_bip32` | Constitutional Committee Cold Extended Signing Key | +| `ConstitutionalCommitteeColdVerificationKey_ed25519` | Constitutional Committee Cold Verification Key | +| `ConstitutionalCommitteeColdExtendedVerificationKey_ed25519_bip32` | Constitutional Committee Cold Extended Verification Key | + +For hardware implementations: + +| `keyType` | Description | +| ---------------------------------------------------- | ------------------------------------------------------- | +| `ConstitutionalCommitteeColdHWSigningFile_ed25519` | Hardware Constitutional Committee Cold Signing File | +| `ConstitutionalCommitteeColdVerificationKey_ed25519` | Hardware Constitutional Committee Cold Verification Key | + +#### Constitutional Committee Hot Keys + +Supporting tooling should clearly label these key pairs as "Constitutional Committee Hot Keys". + +| `keyType` | Description | +| ----------------------------------------------------------------- | ------------------------------------------------------ | +| `ConstitutionalCommitteeHotSigningKey_ed25519` | Constitutional Committee Hot Signing Key | +| `ConstitutionalCommitteeHotExtendedSigningKey_ed25519_bip32` | Constitutional Committee Hot Extended Signing Key | +| `ConstitutionalCommitteeHotVerificationKey_ed25519` | Constitutional Committee Hot Verification Key | +| `ConstitutionalCommitteeHotExtendedVerificationKey_ed25519_bip32` | Constitutional Committee Hot Extended Verification Key | + +For hardware implementations: + +| `keyType` | Description | +| --------------------------------------------------- | ------------------------------------------------------ | +| `ConstitutionalCommitteeHotHWSigningFile_ed25519` | Hardware Constitutional Committee Hot Signing File | +| `ConstitutionalCommitteeHotVerificationKey_ed25519` | Hardware Constitutional Committee Hot Verification Key | + +### Versioning + +This CIP is not to be versioned using a traditional scheme, rather if any large technical changes are required then a new proposal must replace this one. +Small changes can be made if they are completely backwards compatible with implementations, but this should be avoided. + +## Rationale: how does this CIP achieve its goals? + +### Derivation + +By standardizing derivation, naming, and tooling conventions we primarily aim to enable wallet interoperability. +By having a standard to generate DRep and constitutional committee credentials from mnemonics, we allow wallets to always be able to discover a user’s governance activities. + +#### Why add a new roles to the 1852 path? + +This approach mirrors how stake keys were rolled out, see [CIP-0011 | Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0011/README.md). +We deem this necessary since these credentials sit alongside each other in the Conway ledger design. + +The alternative would be to define a completely different derivation paths, using a different index in the purpose field, similar to the specification outlined within [CIP-0036](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0036/README.md#derivation-path), but this could introduce complications with HW wallet implementations. + +#### Why not multi-DRep/CC wallet accounts? + +We believe the overhead that would be introduced by multi-DRep accounts or multi-constitutional-committee is an unjustified expense. +Future iterations of this specification may expand on this, but at present this is seen as unnecessary. +This avoids the need for DRep, cc hot or cc cold key discovery. + +We model this on how stake keys are generally handled by wallets. +If required, another CIP could, of course, introduce a multi-DRep/CC method. + +### Encoding + +#### Why not allow network tags? + +For simplicity, we have omitted network tags within the encoding. +This is because we have modeled DRep IDs and CC credentials on stake pool operator IDs, which similarly do not include a network tag. + + +The advantage of including a network tag would be to reduce the likelihood of mislabelling a DRep’s network of operation (eg Preview v Cardano mainnet). + +## Path to Active + +### Acceptance Criteria + +- [ ] The derivation path is used by three wallet implementers (software and/or hardware). +- [ ] The tooling definitions are used across at least two tools. + +### Implementation Plan + +- [ ] Author to provide an example implementation inside a HD wallet. + +## Copyright + +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). diff --git a/CIP-1852/README.md b/CIP-1852/README.md index 021b47cac8..7e20338ba9 100644 --- a/CIP-1852/README.md +++ b/CIP-1852/README.md @@ -50,11 +50,14 @@ Example: `m / 1852' / 1815' / 0' / 0 / 0` Here, `role` can be the following -| Name | Value | Description -|----------------|-------|------------- -| External chain | `0` | Same as defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) -| Internal chain | `1` | Same as defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) -| Staking Key | `2` | See [CIP11](https://cips.cardano.org/cips/cip11) +| Name | Value | Description +| --- | ----- | ------------ +| External chain | `0` | Same as defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) +| Internal chain | `1` | Same as defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) +| Staking Key | `2` | See [CIP-0011](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0011/README.md) +| DRep Key | `3` | See [CIP-0105](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md) +| Constitutional Committee Cold Key | `4` | See [CIP-0105](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md) +| Constitutional Committee Hot Key | `5` | See [CIP-0105](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md) Wallets **MUST** implement this new scheme using the master node derivation algorithm from Icarus with sequential addressing (see [CIP3](https://cips.cardano.org/cips/cip3) for more information) diff --git a/README.md b/README.md index c23310d0ee..5d68db2269 100644 --- a/README.md +++ b/README.md @@ -92,6 +92,7 @@ CIP Editors meetings are public, recorded, and [published on Youtube](https://ww | 0095 | [Web-Wallet Bridge - Governance](./CIP-0095) | Proposed | | 0101 | [Integration of keccak256 into Plutus](./CIP-0101) | Proposed | | 0102 | [Royalty Datum Metadata](./CIP-0102) | Proposed | +| 0105 | [Conway Era Key Chains for HD Wallets](./CIP-0105) | Proposed | | 0381 | [Plutus Support for Pairings Over BLS12-381](./CIP-0381) | Proposed | | 1694 | [A proposal for entering the Voltaire phase](./CIP-1694) | Proposed | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](./CIP-1852/) | Active | @@ -100,7 +101,7 @@ CIP Editors meetings are public, recorded, and [published on Youtube](https://ww | 1855 | [Forging policy keys for HD Wallets](./CIP-1855/) | Active | | 9999 | [Cardano Problem Statements](./CIP-9999/) | Active | -

Last updated on 2023-10-17

+

Last updated on 2023-11-28

> 💡 For more details about CIP statuses, refer to [CIP-0001](./CIP-0001). @@ -120,7 +121,7 @@ Below are listed tentative CIPs still under discussion with the community. They | 0077? | [Verified Stake Pool Identity](https://github.com/cardano-foundation/CIPs/pull/361) | | 0079? | [Implement Ouroboros Leios to increase Cardano throughput](https://github.com/cardano-foundation/CIPs/pull/379) | | 0087? | [Maybe Datum](https://github.com/cardano-foundation/CIPs/pull/440) | -| 0088? | [Native Asset Policy Registration/Information Certificates](https://github.com/cardano-foundation/CIPs/pull/467) | +| 0088? | [Token Policy Registration](https://github.com/cardano-foundation/CIPs/pull/467) | | 0089? | [Beacon Tokens & Distributed Dapps](https://github.com/cardano-foundation/CIPs/pull/466) | | 0090? | [Extendable dApp-Wallet Web Bridge](https://github.com/cardano-foundation/CIPs/pull/462/) | | 0091? | [Don't force Built-In functions](https://github.com/cardano-foundation/CIPs/pull/459) | @@ -131,9 +132,8 @@ Below are listed tentative CIPs still under discussion with the community. They | 0100? | [Governance Metadata](https://github.com/cardano-foundation/CIPs/pull/556) | | 0103? | [Web-Wallet Bridge - Bulk transaction signing](https://github.com/cardano-foundation/CIPs/pull/587) | | 0104? | [Web-Wallet Bridge - Account public key](https://github.com/cardano-foundation/CIPs/pull/588) | -| 0105? | [Conway Era Key Chains for HD Wallets](https://github.com/cardano-foundation/CIPs/pull/597) | -

Last updated on 2023-11-14

+

Last updated on 2023-11-28

## Cardano Problem Statements (CPS) @@ -157,8 +157,9 @@ Below are listed tentative CPSs still under discussion with the community. They | 0006? | [Governance Security](https://github.com/cardano-foundation/CIPs/pull/491) | | 0008? | [Domain Name Resolution](https://github.com/cardano-foundation/CIPs/pull/605) | | 0009? | [Coin Selection Including Native Tokens](https://github.com/cardano-foundation/CIPs/pull/611) | +| 0010? | [Wallet Connectors](https://github.com/cardano-foundation/CIPs/pull/619) | -

Last updated on 2023-11-14

+

Last updated on 2023-11-28

## Stalled / Waiting For Authors diff --git a/assets/css/styles.css b/assets/css/styles.css deleted file mode 100644 index 9237449d5d..0000000000 --- a/assets/css/styles.css +++ /dev/null @@ -1,476 +0,0 @@ -:root { - --nc-font-sans: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; - --nc-font-mono: Consolas, monaco, 'Ubuntu Mono', 'Liberation Mono', 'Courier New', Courier, monospace; - --nc-tx-1: #000000; - --nc-tx-2: #1A1A1A; - --nc-bg-1: #FFFFFF; - --nc-bg-2: #F6F8FA; - --nc-bg-3: #E5E7EB; - --nc-lk-1: #0070F3; - --nc-lk-2: #0366D6; - --nc-lk-tx: #FFFFFF; - --nc-ac-1: #79FFE1; - --nc-ac-tx: #0C4047; -} - -@media (prefers-color-scheme: light) { - :root { - --nc-tx-1: #000000; - --nc-tx-2: #111111; - --nc-bg-1: #ffffff; - --nc-bg-2: #eeeeee; - --nc-bg-3: #dddddd; - --nc-lk-1: #3291FF; - --nc-lk-2: #0070F3; - --nc-lk-tx: #000000; - --nc-ac-1: #7928CA; - --nc-ac-tx: #000000; - } -} - -* { - /* Reset margins and padding */ - margin: 0; - padding: 0; -} - -address, -area, -article, -aside, -audio, -blockquote, -datalist, -details, -dl, -fieldset, -figure, -form, -input, -iframe, -img, -meter, -nav, -ol, -optgroup, -option, -output, -p, -pre, -progress, -ruby, -section, -table, -textarea, -ul, -video { - /* Margins for most elements */ - margin-bottom: 1rem; -} - -html,input,select,button { - /* Set body font family and some finicky elements */ - font-family: var(--nc-font-sans); -} - -body { - /* Center body in page */ - margin: 0 auto; - max-width: 750px; - padding: 2rem; - border-radius: 6px; - overflow-x: hidden; - word-break: break-word; - overflow-wrap: break-word; - background: var(--nc-bg-1); - - /* Main body text */ - color: var(--nc-tx-2); - font-size: 1.03rem; - line-height: 1.5; -} - -::selection { - /* Set background color for selected text */ - background: var(--nc-ac-1); - color: var(--nc-ac-tx); -} - -h1,h2,h3,h4,h5,h6 { - line-height: 1; - color: var(--nc-tx-1); - padding-top: .875rem; -} - -h1, -h2, -h3 { - color: var(--nc-tx-1); - padding-bottom: 2px; - margin-bottom: 8px; - border-bottom: 1px solid var(--nc-bg-2); -} - -h4, -h5, -h6 { - margin-bottom: .3rem; -} - -h1 { - font-size: 2.25rem; -} - -h2 { - font-size: 1.85rem; -} - -h3 { - font-size: 1.55rem; -} - -h4 { - font-size: 1.25rem; -} - -h5 { - font-size: 1rem; -} - -h6 { - font-size: .875rem; -} - -a { - color: var(--nc-lk-1); -} - -a:hover { - color: var(--nc-lk-2); -} - -abbr:hover { - /* Set the '?' cursor while hovering an abbreviation */ - cursor: help; -} - -blockquote { - padding: 1.5rem; - background: var(--nc-bg-2); - border-left: 5px solid var(--nc-bg-3); -} - -abbr { - cursor: help; -} - -blockquote *:last-child { - padding-bottom: 0; - margin-bottom: 0; -} - -header { - background: var(--nc-bg-2); - border-bottom: 1px solid var(--nc-bg-3); - padding: 2rem 1.5rem; - - /* This sets the right and left margins to cancel out the body's margins. It's width is still the same, but the background stretches across the page's width. */ - - margin: -2rem calc(0px - (50vw - 50%)) 2rem; - - /* Shorthand for: - - margin-top: -2rem; - margin-bottom: 2rem; - - margin-left: calc(0px - (50vw - 50%)); - margin-right: calc(0px - (50vw - 50%)); */ - - padding-left: calc(50vw - 50%); - padding-right: calc(50vw - 50%); -} - -header h1, -header h2, -header h3 { - padding-bottom: 0; - border-bottom: 0; -} - -header > *:first-child { - margin-top: 0; - padding-top: 0; -} - -header > *:last-child { - margin-bottom: 0; -} - -a button, -button, -input[type="submit"], -input[type="reset"], -input[type="button"] { - font-size: 1rem; - display: inline-block; - padding: 6px 12px; - text-align: center; - text-decoration: none; - white-space: nowrap; - background: var(--nc-lk-1); - color: var(--nc-lk-tx); - border: 0; - border-radius: 4px; - box-sizing: border-box; - cursor: pointer; - color: var(--nc-lk-tx); -} - -a button[disabled], -button[disabled], -input[type="submit"][disabled], -input[type="reset"][disabled], -input[type="button"][disabled] { - cursor: default; - opacity: .5; - - /* Set the [X] cursor while hovering a disabled link */ - cursor: not-allowed; -} - -.button:focus, -.button:hover, -button:focus, -button:hover, -input[type="submit"]:focus, -input[type="submit"]:hover, -input[type="reset"]:focus, -input[type="reset"]:hover, -input[type="button"]:focus, -input[type="button"]:hover { - background: var(--nc-lk-2); -} - -code, -pre, -kbd, -samp { - /* Set the font family for monospaced elements */ - font-family: var(--nc-font-mono); -} - -code, -samp, -kbd, -pre { - /* The main preformatted style. This is changed slightly across different cases. */ - background: var(--nc-bg-2); - border: 1px solid var(--nc-bg-3); - border-radius: 4px; - padding: 3px 6px; - font-size: 0.9rem; -} - -kbd { - /* Makes the kbd element look like a keyboard key */ - border-bottom: 3px solid var(--nc-bg-3); -} - -pre { - padding: 1rem 1.4rem; - max-width: 100%; - overflow: auto; -} - -pre code { - /* When is in a 
, reset it's formatting to blend in */
-	background: inherit;
-	font-size: inherit;
-	color: inherit;
-	border: 0;
-	padding: 0;
-	margin: 0;
-}
-
-code pre {
-	/* When 
 is in a , reset it's formatting to blend in */
-	display: inline;
-	background: inherit;
-	font-size: inherit;
-	color: inherit;
-	border: 0;
-	padding: 0;
-	margin: 0;
-}
-
-details {
-	/* Make the 
 look more "clickable" */
-	padding: .6rem 1rem;
-	background: var(--nc-bg-2);
-	border: 1px solid var(--nc-bg-3);
-	border-radius: 4px;
-}
-
-summary {
-	/* Makes the  look more like a "clickable" link with the pointer cursor */
-	cursor: pointer;
-	font-weight: bold;
-}
-
-details[open] {
-	/* Adjust the 
 padding while open */
-	padding-bottom: .75rem;
-}
-
-details[open] summary {
-	/* Adjust the 
 padding while open */
-	margin-bottom: 6px;
-}
-
-details[open]>*:last-child {
-	/* Resets the bottom margin of the last element in the 
 while 
 is opened. This prevents double margins/paddings. */
-	margin-bottom: 0;
-}
-
-dt {
-	font-weight: bold;
-}
-
-dd::before {
-	/* Add an arrow to data table definitions */
-	content: '→ ';
-}
-
-hr {
-	/* Reset the border of the 
 separator, then set a better line */
-	border: 0;
-	border-bottom: 1px solid var(--nc-bg-3);
-	margin: 1rem auto;
-}
-
-fieldset {
-	margin-top: 1rem;
-	padding: 2rem;
-	border: 1px solid var(--nc-bg-3);
-	border-radius: 4px;
-}
-
-legend {
-	padding: auto .5rem;
-}
-
-table {
-	/* border-collapse sets the table's elements to share borders, rather than floating as separate "boxes". */
-	border-collapse: collapse;
-	width: 100%
-}
-
-td,
-th {
-	border: 1px solid var(--nc-bg-3);
-	text-align: left;
-  padding: .5rem;
-  word-break: normal;
-}
-
-th {
-  background: var(--nc-bg-2);
-  white-space: nowrap;
-}
-
-tr:nth-child(even) {
-	/* Set every other cell slightly darker. Improves readability. */
-	background: var(--nc-bg-2);
-}
-
-table caption {
-	font-weight: bold;
-	margin-bottom: .5rem;
-}
-
-textarea {
-	/* Don't let the