Merge branch 'master' into crptmppt-meeting26notes

cardano-foundation · Jul 28, 2021 · be77896 · be77896
2 parents e52afc4 + 15a0cd1
commit be77896
Show file tree

Hide file tree

Showing 6 changed files with 372 additions and 0 deletions.
diff --git a/CIP-0010/registry.json b/CIP-0010/registry.json
@@ -1,4 +1,8 @@
 [
+  {
+    "transaction_metadatum_label": 721,
+    "description": "CIP-0025 - NFT Metadata Standard"
+  },
   {
     "transaction_metadatum_label": 1967,
     "description": "nut.link metadata oracles registry"

diff --git a/CIP-0017/CIP-0017.json b/CIP-0017/CIP-0017.json
@@ -0,0 +1,54 @@
+{ "title": "CIP-0017 - Cardano Delegation Portfolio"
+, "$schema": "https://json-schema.org/draft-07/schema"
+, "type": "object"
+, "required":
+    [ "name"
+    , "pools"
+    ]
+, "properties":
+    { "name":
+        { "type": "string"
+        , "minLength": 1
+        }
+    , "description":
+        { "type": "string"
+        , "minLength": 1
+        }
+    , "author":
+        { "type": "string"
+        , "minLength": 1
+        }
+    , "pools":
+        { "type": "array"
+        , "minItems": 1
+        , "items":
+            { "type": "object"
+            , "required":
+                [ "id"
+                , "weight"
+                ]
+            , "properties":
+                { "id":
+                    { "type": "string"
+                    , "minLength": 56
+                    , "maxLength": 56
+                    , "contentEncoding": "base16"
+                    }
+                , "name":
+                    { "type": "string"
+                    , "minLength": 1
+                    }
+                , "ticker":
+                    { "type": "string"
+                    , "minLength": 3
+                    , "maxLength": 5
+                    }
+                , "weight":
+                    { "type": "integer"
+                    , "minimum": 1
+                    }
+                }
+            }
+        }
+    }
+}
diff --git a/CIP-0017/CIP-0017.md b/CIP-0017/CIP-0017.md
@@ -0,0 +1,86 @@
+---
+CIP: 17
+Title: Cardano Delegation Portfolio
+Authors: Matthias Benkort <matthias.benkort@iohk.io>
+Comments-Summary: A Common format for sharing Cardano delegation portfolios
+Comments-URI: https://github.com/cardano-foundation/CIPs/wiki/Comments:CIP-0017
+Status: Active
+Type: Standards
+Created: 2020-04-02
+License: CC-BY-4.0
+---
+
+# Abstract
+
+This document details a common format for sharing Cardano delegation portfolio across various tools and wallets. 
+
+# Motivation
+
+Stakeholders have indicated the desire to split their stake in various sizes and delegate to n pools from a single wallet/mnemonic. Albeit there are no monetary incentive for users to do this, the desire to drive decentralisation is sufficiently prevalent to justify it. Furthermore, stakeholders want to introduce a certain social element to this activity by sharing their delegation portfolio with other stakeholders. This specification should help to standardize the representation of portfolios across tools for more interoperability. 
+
+# Specification
+
+### Overview
+
+We'll use JSON as a data format for it is commonly used and supported across many programming languages, and is also relatively readable on itself. Portfolios should abide by the [JSON schema given in appendix](CIP-0017.json). 
+
+At minima, a portfolio should cover a list of delegation choices (pools and weights) and have a human-readable name for easier identification. 
+
+### Weights
+
+For each pool, we demand a `weight` which can capture a certain stake proportion within the portfolio. The value is an integer, and relative to other weights in the portfolio. For example, a portfolio with two pools and respective weights of `1` and `2` means that we expect users to assign twice more stake to the second pool than the first. Fundamentally, this means that for every 3 Ada, 1 Ada should go to the first pool, and 2 Ada should go to the second. Note that this is equivalent to having weights of `10`/`20` or `14` / `28`. Weights are ultimately interpreted as fractions.
+
+Portfolios which treat all stake pools equally should use the same weight (e.g. `1`) for each pool. 
+
+# Rationale
+
+1. JSON is widely used, widely supported and quite lightweight. Makes for a reasonable choice of data format.
+
+2. Using JSON schema for validation is quite common when dealing with JSON and it's usually sufficiently precise to enable good interoperability. 
+
+3. The portfolio should only capture information that are not subject to radical change. That is, stake pools parameters like pledge or fees are excluded since they can be changed fairly easily using on-chain certificate updates. 
+
+4. The JSON schema doesn't enforce any `additionalProperties: false` for neither the top-level object definition nor each stake pool objects. This allows for open extension of the objects with custom fields at the discretion of applications implementing this standard. The semantic of well-known properties specified in this document is however fixed.
+
+5. Since the portfolio format isn't _immediately user-facing_, we favor base16 over bech32 for the pool id's encoding for there's better support and tooling for the former.
+
+# Backwards Compatibility
+
+## Adafolio (https://adafolio.com)
+
+The format used by Adafolio share a lot of similarities with the proposed format in this CIP. In order to power its frontend user interface, Adafolio contains however several fields which we consider _too volatile_ and unnecessary to the definition of a portfolio. This doesn't preclude the format used by Adafolio as a valid portfolio format (see also point (4). in the rationale above).
+
+The only point of incompatibility regards the `pool_id` field (in Adafolio) vs the `id` field (in this proposal) which we deem more consistent with regards to other field. 
+
+# Reference Implementation(s)
+
+##  Examples
+
+```json
+{ "name": "Metal 🤘"
+, "description": "Pools supporting Metal music across the world."
+, "pools": 
+  [ { "id": "d59123f4dce7c62fa74bd37a759c7ba665dbabeb28f08b4e5d4802ca"
+    , "name": "Dark Tranquility"
+    , "ticker": "DARK"
+    , "weight": 42
+    }
+  , { "id": "5f3833027fe8c8d63bc5e75960d9a22df52e41bdf62af5b689663c50"
+    , "ticker": "NITRO"
+    , "weight": 14
+    }
+  , { "id": "a16abb03d87b86f30bb743aad2e2504b126286fe744d3d2f6a0b4aec"
+    , "name": "Loudness"
+    , "ticker": "LOUD"
+    , "weight": 37
+    }
+  , { "id": "9f9bdee3e053e3102815b778db5ef8d55393f7ae83b36f906f4c3a47"
+    , "weight": 25
+    }
+  ]
+}
+```
+
+# Copyright
+
+CC-BY-4.0
diff --git a/CIP-0024/CIP-0024.md b/CIP-0024/CIP-0024.md
@@ -0,0 +1,100 @@
+---
+CIP: 24
+Title: Non-Centralizing Rankings
+Authors: Shawn McMurdo <shawn_mcmurdo@yahoo.com>
+Comments-URI: https://forum.cardano.org/t/how-to-improve-daedalus-rankings/40478
+Status: Draft
+Type: Standards
+Created: 2020-09-15
+License: CC-BY-4.0
+---
+
+## Summary
+
+Make Daedalus rankings more fair and non-centralizing by modifying the ranking methodology.
+
+## Abstract
+
+Modify the current ranking system by removing the centralizing Nash Equilibrium goal of the ranking methodology in order to give more fair rankings and improve the viability of the stake pool operator community and the network overall.  To do this we need to remove the stated goal of having k fully saturated pools and all other pools having no stake other than owner pledge, which goes against the Cardano goal of decentralization.
+
+## Motivation
+
+There are two main reasons for changing the current ranking methodology:
+
+1. Allow for more than k successful stakepools.
+
+2. Provide better decentralization away from a very few stakepool operators creating many pools.
+
+## Specification
+
+This is a modification of the ranking methodology defined in section 5.6 Non-Myopic Utility of “Shelley Ledger: Delegation/Incentives Design Spec. (SL-D1 v.1.20, 2020/07/06)” as follows:
+
+1. Remove the following statement from section 5.6:
+
+"The idea is to first rank all pools by “desirability”, to then assume that the k most desirable
+pools will eventually be saturated, whereas all other pools will lose all their members, then to
+finally base all reward calculations on these assumptions."
+
+2. Remove the following statement from section 5.6.1:
+
+"We predict that pools with rank ≤ k will eventually be saturated, whereas pools with rank
+> k will lose all members and only consist of the owner(s)."
+
+3. Add the following to section 5.6.1:
+
+For all pools with proposed_pool_stake greater than saturation_warning_stake add k to their rank.
+Where:
+proposed_pool_stake = pool_live_stake + proposed_user_stake
+saturation_warning_stake = (total_stake / k) * saturation_warning_level
+saturation_warning_level is a real number greater than 0 representing the percent of saturation which is undesirable.  A proposed value for saturation_warning_level is 0.95 meaning 95% saturated.
+
+For example, if a pool has non-myopic desirability rank of 3, pool_live_stake of 207m ADA, proposed_user_stake of 100k ADA with total_stake of 31.7b ADA, k = 150 and saturation_warning_level = 0.95, we would calculate:
+207m + 100k > (31.7b / 150) * 0.95
+and see that
+207.1m > 200.8m
+is true so we would change the pool rank to 153 (3 + k) and all pools previously ranked 4 through 153 would move up 1 rank.
+
+4. Remove secion 5.6.2.
+
+5. Remove section 5.6.3.
+
+6. Remove section 5.6.4.
+
+7. Add to secion 5.6.5.
+
+For example, apparent performance, desirability and ranking can be made non-myopic for ranking purposes as follows:
+
+dnm[n] :=
+ average(d[1]...d[n],and[n + 1]...and[i])  if n < i
+ average(d[1]...d[n])  if n = i
+ (dnm[n - 1] * h) + (d[n] * (1 - h))  otherwise.
+
+where:
+n = epoch number beginning at n = 1 in the first epoch that the pool is eligible for potential rewards.
+dnm[n] = the non-myopic desirability of the pool in the nth epoch.
+d[n] = the desirability in the nth epoch unaware of historical desirability.
+and[n] = the average desirability of the network as a whole in the nth epoch unaware of historical desirability.
+h = historical influence factor, which is any real number between 0 and 1 exlusive.
+i = integer(1 / h) which is the initial number of epochs during which we use the average desirability
+
+As an example, setting h to 0.1 would mean that the initial number of epochs for using the averaging functions (i) would be 10.  If a pool has been eligible to receive rewards (n) for 3 epochs then we use the average of the pool's desirability for those 3 epochs and the overall network desirability for the prior 7 epochs.  After the 10th epoch we would use 90% of the previous epoch's non-myopic historical desirability and 10% of the current epoch's desirability to arrive at the new non-myopic desirability.
+
+This gives a more reasonable ranking for newer pools that do not have enough historical data to provide fair rankings.
+
+## Rationale
+
+Using this non-centralizing ranking methodology gives a more fair ranking of stakepools based on performance, pledge and saturation which will encourage delegators to choose better pools.
+It will also bring the rankings more in line with the general Cardano principle of increasing decentralization.
+
+## Backward Compatibility
+
+This proposal does not break backwards compatability because it is an offchain change.
+
+## Implementations
+
+If someone will show me where the current desirability equation is implemented in the code, I could produce an implementation of this change as a pull request.
+
+## Copyright
+
+This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)
+
diff --git a/CIP-0025/CIP-0025.md b/CIP-0025/CIP-0025.md
@@ -0,0 +1,127 @@
+---
+CIP: 25
+Title: NFT Metadata Standard
+Authors: Alessandro Konrad <alessandro.konrad@live.de>, Smaug <smaug@pool.pm>
+Comments-URI:
+Status: Draft
+Type: Informational
+Created: 2021-04-08
+Post-History: https://forum.cardano.org/t/cip-nft-metadata-standard/45687 and https://www.reddit.com/r/CardanoDevelopers/comments/mkhlv8/nft_metadata_standard/
+License: CC-BY-4.0
+---
+
+## Abstract
+
+This proposal defines an NFT Metadata Standard for Native Tokens.
+
+## Motivation
+
+Tokens on Cardano are a part of the ledger. Unlike on Ethereum, where metadata can be attached to a token through a smart contract, this isn't possible on Cardano because tokens are native and Cardano uses a UTxO ledger, which makes it hard to directly attach metadata to a token.
+So the link to the metadata needs to be established differently.
+Cardano has the ability to send metadata in a transaction, that's the way we can create a link between a token and the metadata. To make the link unique, the metadata should be appended to the same transaction, where the token forge happens:
+
+> Given a token in a EUTXOma ledger, we can ask “where did this token come from?” Since tokens
+> are always created in specific forging operations, we can always trace them back through their
+> transaction graph to their origin.
+
+(Section 4.1 in the paper: https://hydra.iohk.io/build/5400786/download/1/eutxoma.pdf)
+
+## Considerations
+
+That being said, we have unique metadata link to a token and can always prove that with 100% certainty. No one else can manipulate the link except if the policy allows it to ([update mechanism](#update-metadata-link-for-a-specific-token)).
+
+## Specification
+
+This is the registered `transaction_metadatum_label` value
+
+| transaction_metadatum_label | description  |
+| --------------------------- | ------------ |
+| 721                         | NFT Metadata |
+
+### Structure
+
+The structure allows for multiple token mints, also with different policies, in a single transaction.
+
+```
+{
+  "721": {
+    "<policy_id>": {
+      "<asset_name>": {
+        "name": <string>,
+
+        "image": <uri | array>,
+        "mediaType": "image/<mime_sub_type>",
+
+        "description": <string | array>
+
+        "files": [{
+          "name": <string>,
+          "mediaType": <mime_type>,
+          "src": <uri | array>,
+          <other_properties>
+        }],
+
+        <other properties>
+      }
+    }
+    "version": "1.0"
+  }
+}
+```
+
+The **`image`** and **`name`** property are marked as required. **`image`** should be an URI pointing to a resource with mime type `image/*` used as thumbnail or as actual link if the NFT is an image (ideally <= 1MB).
+
+The **`description`** property is optional.
+
+The **`mediaType`** and **`files`** properties are optional.<br /> **`mediaType`** is however required inside **`files`**. The **`src`** property inside **`files`** is an URI pointing to a resource of this mime type. If the mime type is `image/*`, **`mediaType`** points to the same image, like the on in the **`image`** property, but in an higher resolution.
+
+The **`version`** property is also optional. If not specified the version is `1.0`. It will become mandatory in future versions if needed.
+
+This structure really just defines the basis. New properties and standards can be defined later on for varies uses cases. That's why there is an "other properties" tag.
+
+The retrieval of the metadata should be the same for all however.
+
+Optional fields allow to save space in the blockchain. Consequently the minimal structure for a single token is:
+
+```
+{
+  "721": {
+    "<policy_id>": {
+      "<asset_name>": {
+        "name": <string>,
+        "image": <uri | array>,
+      }
+    }
+  }
+}
+```
+
+### Retrieve valid metadata for a specific token
+
+As mentioned above this metadata structure allows to have either one token or multiple tokens with also different policies in a single mint transaction. A third party tool can then fetch the token metadata seamlessly. It doesn't matter if the metadata includes just one token or multiple. The proceedure for the third party is always the same:
+
+1. Find the latest mint transaction with the label 721 in the metadata of the specific token
+2. Lookup the 721 key
+3. Lookup the Policy Id of the token
+4. Lookup the Asset name of the token
+5. You end up with the correct metadata for the token
+
+### Update metadata link for a specific token
+
+Using the latest mint transaction with the label 721 as valid metadata for a token allows to update the metadata link of this token. As soon as a new mint transaction is occurring including metadata with the label 721, the metadata link is considered updated and the new metadata should be used. This is only possible if the policy allows to mint or burn the same token again.
+
+## Backward Compatibility
+
+To keep NFT metadata compatible with changes coming up in the future, we use the **`version`** property. Version `1.0` is used in the current metadata structure of this CIP.
+Version `2.0` will introduce [schema.org](https://schema.org).
+
+## References
+
+- Mime type: https://tools.ietf.org/html/rfc6838.
+- CIP about reserved labels: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/CIP-0010.md
+- EIP-721: https://eips.ethereum.org/EIPS/eip-721
+- URI: https://tools.ietf.org/html/rfc3986, https://tools.ietf.org/html/rfc2397
+
+## Copyright
+
+This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).
diff --git a/README.md b/README.md
@@ -1,5 +1,6 @@
 # Cardano Improvement Proposals (CIPs)
 
+
 Cardano Improvement Proposals (CIPs) describe standards, processes; or provide general guidelines or information to the Cardano Community. It is a formal, technical communication process that exists off-chain.
 The current process is described in details in [CIP1 - "CIP Process"](./CIP-0001/CIP-0001.md).