From 0311eebcb1d962e134e9b69e54affd77e5925708 Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Wed, 4 Dec 2019 18:11:29 +0100 Subject: [PATCH 01/11] init psp from template --- PSPs/drafts/psp-5.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 PSPs/drafts/psp-5.md diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md new file mode 100644 index 0000000..89223cf --- /dev/null +++ b/PSPs/drafts/psp-5.md @@ -0,0 +1,27 @@ +# Title + +* **PSP Number:** [To be assigned] +* **Authors:** [Name and Email or GitHub Username] +* **Status:** [Draft, Call for Feedback, Accepted, Integrated] +* **Created:** [yyyy-mm-dd] +* **Reference Implementation** [Link to a first reference implementation] + +## Summary + +A summary of the standard and the addressed issue. + +## Motivation + +The motivation should describe what motivated the development of the standard as well as why particular decisions were made. + +## Specification + +The specification should describe the feature as detailed as possible. The proposal should be complete, consistent, unambiguous, quantitative, and feasible. + +## Tests + +If applicable, please include a list of potential test cases to validate an implementation. + +## Copyright + +Each PSP must be labeled as placed in the [public domain](https://creativecommons.org/publicdomain/zero/1.0/). From fbd9d46315155a0d93dafc650d49f411790627cc Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Wed, 4 Dec 2019 18:20:25 +0100 Subject: [PATCH 02/11] basic information about document in header --- PSPs/drafts/psp-5.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index 89223cf..3b10355 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -1,10 +1,10 @@ -# Title +# Structure for genesis parameters -* **PSP Number:** [To be assigned] -* **Authors:** [Name and Email or GitHub Username] -* **Status:** [Draft, Call for Feedback, Accepted, Integrated] -* **Created:** [yyyy-mm-dd] -* **Reference Implementation** [Link to a first reference implementation] +* **PSP Number:** 001 +* **Authors:** Fabio Lama +* **Status:** Call for Feedback +* **Created:** 2019-12-04 +* **Reference Implementation:** https://github.com/w3f/polkadot-spec/blob/master/genesis-state/kusama/ksmcc3/kusama.json ## Summary From 79d13d580167564a061dfc0e5e6739755ecf038c Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Wed, 4 Dec 2019 18:56:55 +0100 Subject: [PATCH 03/11] describe summary and motivation --- PSPs/drafts/psp-5.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index 3b10355..b4b4e87 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -8,11 +8,11 @@ ## Summary -A summary of the standard and the addressed issue. +This standard describes the basic JSON structure (refered to as "genesis file") of how genesis parameters including relevant data and metadata of the network should be distributed and processed. ## Motivation -The motivation should describe what motivated the development of the standard as well as why particular decisions were made. +The [Polkadot specification](https://github.com/w3f/polkadot-spec) describes how genesis parameters should be inserted into the state storage, but networks contain additional useful information such as boot nodes, protocol identifiers, telemetry endpoints and properties that are not part of the genesis state. A standardized JSON structure allows a portable integration from different Polkadot implementations, allowing those implementations to correctly use and process the data. ## Specification From 36517c1bcfa654cce41d807800ad61a4596f905e Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Wed, 4 Dec 2019 19:29:37 +0100 Subject: [PATCH 04/11] adjust motivation description --- PSPs/drafts/psp-5.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index b4b4e87..351a69b 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -12,7 +12,7 @@ This standard describes the basic JSON structure (refered to as "genesis file") ## Motivation -The [Polkadot specification](https://github.com/w3f/polkadot-spec) describes how genesis parameters should be inserted into the state storage, but networks contain additional useful information such as boot nodes, protocol identifiers, telemetry endpoints and properties that are not part of the genesis state. A standardized JSON structure allows a portable integration from different Polkadot implementations, allowing those implementations to correctly use and process the data. +The [Polkadot specification](https://github.com/w3f/polkadot-spec) describes how genesis parameters should be inserted into the state storage, but networks contain additional useful information such as boot nodes, protocol identifiers, telemetry endpoints and properties that are not part of the genesis state. A standardized JSON structure allows a portable integration for different Polkadot implementations, nodes and and other tools, allowing these software to correctly use and process the data. ## Specification From 79685938e702a50744498a7e7922c282a61fa22d Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Thu, 5 Dec 2019 12:22:34 +0100 Subject: [PATCH 05/11] spec json data types, add example --- PSPs/drafts/psp-5.md | 55 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 53 insertions(+), 2 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index 351a69b..73aafff 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -8,16 +8,67 @@ ## Summary -This standard describes the basic JSON structure (refered to as "genesis file") of how genesis parameters including relevant data and metadata of the network should be distributed and processed. +This standard describes the basic JSON structure (refered to as "genesis file") in which genesis parameters including relevant data and metadata of the network should be saved and distributed. ## Motivation -The [Polkadot specification](https://github.com/w3f/polkadot-spec) describes how genesis parameters should be inserted into the state storage, but networks contain additional useful information such as boot nodes, protocol identifiers, telemetry endpoints and properties that are not part of the genesis state. A standardized JSON structure allows a portable integration for different Polkadot implementations, nodes and and other tools, allowing these software to correctly use and process the data. +The [Polkadot specification](https://github.com/w3f/polkadot-spec) describes how genesis parameters should be inserted into the state storage, but networks contain additional useful information such as boot nodes, protocol identifiers, telemetry endpoints and properties that are not part of the genesis state. A standardized JSON structure allows a portable integration for different Polkadot implementations, nodes and and other tools, allowing these software to correctly read and process the data. ## Specification The specification should describe the feature as detailed as possible. The proposal should be complete, consistent, unambiguous, quantitative, and feasible. +Format: +|Name |Type |Mandatory|Description| +|------------------|-------------------------|---------|-----------| +|name |String |YES | | +|id |String |YES | | +|bootNodes |Array[String] |YES | | +|telemetryEndpoints|Array[Array[String, Int]]|NO | | +|protocolId |String |NO | | +|properties |Map[String:Value] |NO | | +|consensusEngine |null |YES | | +|genesis |Object->Genesis |YES | | + +Object: Genesis +|Name |Type |Mandatory|Description| +|------------------|-------------------------|---------|-----------| +|raw |Map[String:String] |YES | | + +Example: +``` +{ + "name": "Kusama CC3", + "id": "ksmcc3", + "bootNodes": [ + "/dns4/p2p.cc3-0.kusama.network/tcp/30100/p2p/QmeCit3Nif4VfNqrEJsdYHZGcKzRCnZvGxg6hha1iNj4mk", + "/dns4/p2p.cc3-1.kusama.network/tcp/30100/p2p/QmchDJtEGiEWf7Ag58HNoTg9jSGzxkSZ23VgmF6xiLKKsZ" + ], + "telemetryEndpoints": [ + [ + ["wss://telemetry.polkadot.io/submit/", 0] + ] + ], + "protocolId": "ksmcc3", + "properties": { + "ss58Format": 2, + "tokenDecimals": 12, + "tokenSymbol": "KSM" + }, + "consensusEngine": null, + "genesis": { + "raw": [ + { + "0x9c5d795d0297be56027a4b2464e333979c5d795d0297be56027a4b2464e33397974a8f6e094002e424b603628718939b060c4c6305a73d36a014468c29b8b7d7": "0x00c0e1d0612100000000000000000000", + "0x9c5d795d0297be56027a4b2464e333979c5d795d0297be56027a4b2464e33397997f7003f78328f30c57e6ce10b1956c77d2187fe08441845cc0c18273852039": "0x00703874580800000000000000000000", + ... + }, + {} + ] + } +} +``` + ## Tests If applicable, please include a list of potential test cases to validate an implementation. From db031e4487e068e70b051e58f5e5d22906bf1cef Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Thu, 5 Dec 2019 14:52:28 +0100 Subject: [PATCH 06/11] expand the spec, add todo section --- PSPs/drafts/psp-5.md | 55 +++++++++++++++++++++++++++++--------------- 1 file changed, 36 insertions(+), 19 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index 73aafff..c1166a4 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -10,32 +10,40 @@ This standard describes the basic JSON structure (refered to as "genesis file") in which genesis parameters including relevant data and metadata of the network should be saved and distributed. +The detailed description and requirements for the genesis parameters can be found in the [Polkadot Runtime Environment Specification](https://github.com/w3f/polkadot-spec). + ## Motivation -The [Polkadot specification](https://github.com/w3f/polkadot-spec) describes how genesis parameters should be inserted into the state storage, but networks contain additional useful information such as boot nodes, protocol identifiers, telemetry endpoints and properties that are not part of the genesis state. A standardized JSON structure allows a portable integration for different Polkadot implementations, nodes and and other tools, allowing these software to correctly read and process the data. +The Polkadot Runtime Environment Specification describes how genesis parameters should be inserted into the state storage, but networks contain additional useful information such as boot nodes, protocol identifiers, telemetry endpoints and properties that are not part of the genesis state. A standardized JSON structure allows a portable integration for different Polkadot implementations, nodes and and other tools, allowing these software to correctly read and process the data. ## Specification -The specification should describe the feature as detailed as possible. The proposal should be complete, consistent, unambiguous, quantitative, and feasible. +The genesis file must be represented in the following format: + +|Name |Type |Mandatory|Description| +|------------------|-------------------------|---------|-----------| +|name |String |YES |The name of the chain network| +|id |String |YES |Client-side parameter for logging, directory names, etc | +|bootNodes |Array[String] |YES |List of `libp2p` [Multiaddresses](https://docs.libp2p.io/concepts/addressing/), including protocol id and multihash| +|telemetryEndpoints|Array[Array[String, Int]]|NO |A list of Websocket telemetry endpoints pairs, where the first value is a address prefixed with a `wss://` schema and the second value is a number indicating the logging verbosity| +|protocolId |String |NO |The identifier to of the chain network, gets sent with each request| +|properties |Object->Properties |NO |Metadata for the chain network| +|consensusEngine |null |YES |Never used, left only for backward compatibility| +|genesis |Object->Genesis |YES |Contains the genesis parameters| -Format: +**Object:** Properties |Name |Type |Mandatory|Description| |------------------|-------------------------|---------|-----------| -|name |String |YES | | -|id |String |YES | | -|bootNodes |Array[String] |YES | | -|telemetryEndpoints|Array[Array[String, Int]]|NO | | -|protocolId |String |NO | | -|properties |Map[String:Value] |NO | | -|consensusEngine |null |YES | | -|genesis |Object->Genesis |YES | | - -Object: Genesis +|ss58Format |Int |NO |The format of the [ss58 address format]()| +|tokenDecimals |Int |NO |The decimal precision of the native token| +|tokenSymbol |String |NO |Symbol of the native token| + +**Object:** Genesis |Name |Type |Mandatory|Description| |------------------|-------------------------|---------|-----------| -|raw |Map[String:String] |YES | | +|raw |Object[String:String] |YES |The key/values pairs required for the runtime| -Example: +**Example:** ``` { "name": "Kusama CC3", @@ -60,8 +68,7 @@ Example: "raw": [ { "0x9c5d795d0297be56027a4b2464e333979c5d795d0297be56027a4b2464e33397974a8f6e094002e424b603628718939b060c4c6305a73d36a014468c29b8b7d7": "0x00c0e1d0612100000000000000000000", - "0x9c5d795d0297be56027a4b2464e333979c5d795d0297be56027a4b2464e33397997f7003f78328f30c57e6ce10b1956c77d2187fe08441845cc0c18273852039": "0x00703874580800000000000000000000", - ... + "0x9c5d795d0297be56027a4b2464e333979c5d795d0297be56027a4b2464e33397997f7003f78328f30c57e6ce10b1956c77d2187fe08441845cc0c18273852039": "0x00703874580800000000000000000000" }, {} ] @@ -71,8 +78,18 @@ Example: ## Tests -If applicable, please include a list of potential test cases to validate an implementation. +TODO: If applicable, please include a list of potential test cases to validate an implementation. ## Copyright -Each PSP must be labeled as placed in the [public domain](https://creativecommons.org/publicdomain/zero/1.0/). +TODO: Each PSP must be labeled as placed in the [public domain](https://creativecommons.org/publicdomain/zero/1.0/). + +## TODO +- Why is the client side `id` mandatory while `protocol_id` is not? +- Shouldn't `id` and `protocol_id` be the same? +- What does "format" of the ss58 address format mean? +- In the (kusama) JSON file the `property` field has certain key/value pairs, but the Substrate code accepts anything. This behaviour makes sense in terms of the genesis parameters, since those values just get inserted into the state storage. But how can `property` be useful if those values are not predefined? +- What does the second object in `"genesis"` > `"raw"` do? See: `"raw": [{},{}]` +- Since Polkadot has not been released yet, why is `"consensusEngine"` a legacy field? +- What should be defined in the header value "Reference Implemenation"? +- What's the logging verbosity for telemetry endpoints? \ No newline at end of file From 40e5490be64f3d820268160b2345568c9546093e Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Thu, 5 Dec 2019 15:12:56 +0100 Subject: [PATCH 07/11] fixed typos --- PSPs/drafts/psp-5.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index c1166a4..6b4ccd0 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -8,7 +8,7 @@ ## Summary -This standard describes the basic JSON structure (refered to as "genesis file") in which genesis parameters including relevant data and metadata of the network should be saved and distributed. +This standard describes the basic JSON structure (refered to as a "genesis file") in which genesis parameters including relevant data and metadata of the network should be saved and distributed. The detailed description and requirements for the genesis parameters can be found in the [Polkadot Runtime Environment Specification](https://github.com/w3f/polkadot-spec). @@ -25,10 +25,10 @@ The genesis file must be represented in the following format: |name |String |YES |The name of the chain network| |id |String |YES |Client-side parameter for logging, directory names, etc | |bootNodes |Array[String] |YES |List of `libp2p` [Multiaddresses](https://docs.libp2p.io/concepts/addressing/), including protocol id and multihash| -|telemetryEndpoints|Array[Array[String, Int]]|NO |A list of Websocket telemetry endpoints pairs, where the first value is a address prefixed with a `wss://` schema and the second value is a number indicating the logging verbosity| -|protocolId |String |NO |The identifier to of the chain network, gets sent with each request| +|telemetryEndpoints|Array[Array[String, Int]]|NO |A list of Websocket telemetry endpoints pairs, where the first value is an address prefixed with a `wss://` schema and the second value is a number indicating the logging verbosity| +|protocolId |String |NO |The identifier of the chain network, which is sent with each request| |properties |Object->Properties |NO |Metadata for the chain network| -|consensusEngine |null |YES |Never used, left only for backward compatibility| +|consensusEngine |null |YES |Never used; left only for backward compatibility| |genesis |Object->Genesis |YES |Contains the genesis parameters| **Object:** Properties @@ -78,17 +78,18 @@ The genesis file must be represented in the following format: ## Tests -TODO: If applicable, please include a list of potential test cases to validate an implementation. +Multiple genesis files can be found in the Polkadot Runtime Environment specification repository: +- https://github.com/w3f/polkadot-spec/tree/master/genesis-state ## Copyright -TODO: Each PSP must be labeled as placed in the [public domain](https://creativecommons.org/publicdomain/zero/1.0/). +This Polkadot Standards Proposal is placed in the public domain as defined in the [CC0 1.0 Universal (CC0 1.0) Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/). ## TODO -- Why is the client side `id` mandatory while `protocol_id` is not? -- Shouldn't `id` and `protocol_id` be the same? +- Why is the client side `id` mandatory while `protocolId` is not? +- Shouldn't `id` and `protocolId` be the same field/value? - What does "format" of the ss58 address format mean? -- In the (kusama) JSON file the `property` field has certain key/value pairs, but the Substrate code accepts anything. This behaviour makes sense in terms of the genesis parameters, since those values just get inserted into the state storage. But how can `property` be useful if those values are not predefined? +- In the (kusama) JSON file, the `property` field has certain key/value pairs, but the Substrate code accepts anything. This behaviour makes sense in terms of the genesis parameters, since those values just get inserted into the state storage. But how can `property` be useful if those values are not predefined? - What does the second object in `"genesis"` > `"raw"` do? See: `"raw": [{},{}]` - Since Polkadot has not been released yet, why is `"consensusEngine"` a legacy field? - What should be defined in the header value "Reference Implemenation"? From 2bd4785124665b77a8883c9d4fa507f106894e35 Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Thu, 5 Dec 2019 15:54:08 +0100 Subject: [PATCH 08/11] improved description for json format --- PSPs/drafts/psp-5.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index 6b4ccd0..848b49a 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -3,7 +3,7 @@ * **PSP Number:** 001 * **Authors:** Fabio Lama * **Status:** Call for Feedback -* **Created:** 2019-12-04 +* **Created:** 2019-12-05 * **Reference Implementation:** https://github.com/w3f/polkadot-spec/blob/master/genesis-state/kusama/ksmcc3/kusama.json ## Summary @@ -24,8 +24,8 @@ The genesis file must be represented in the following format: |------------------|-------------------------|---------|-----------| |name |String |YES |The name of the chain network| |id |String |YES |Client-side parameter for logging, directory names, etc | -|bootNodes |Array[String] |YES |List of `libp2p` [Multiaddresses](https://docs.libp2p.io/concepts/addressing/), including protocol id and multihash| -|telemetryEndpoints|Array[Array[String, Int]]|NO |A list of Websocket telemetry endpoints pairs, where the first value is an address prefixed with a `wss://` schema and the second value is a number indicating the logging verbosity| +|bootNodes |[String] |YES |An array containing one or multiple `libp2p` [Multiaddresses](https://docs.libp2p.io/concepts/addressing/), including protocol id and multihash| +|telemetryEndpoints|[[String, Int]]|NO |An array of zero, one or multiple telemetry endpoints, where the inner array(s) contain(s) two values. The first value is an address with the full URL scheme and the second value is a number indicating the logging verbosity.| |protocolId |String |NO |The identifier of the chain network, which is sent with each request| |properties |Object->Properties |NO |Metadata for the chain network| |consensusEngine |null |YES |Never used; left only for backward compatibility| @@ -34,7 +34,7 @@ The genesis file must be represented in the following format: **Object:** Properties |Name |Type |Mandatory|Description| |------------------|-------------------------|---------|-----------| -|ss58Format |Int |NO |The format of the [ss58 address format]()| +|ss58Format |Int |NO |The format of the [ss58 address format](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58))| |tokenDecimals |Int |NO |The decimal precision of the native token| |tokenSymbol |String |NO |Symbol of the native token| @@ -88,7 +88,7 @@ This Polkadot Standards Proposal is placed in the public domain as defined in th ## TODO - Why is the client side `id` mandatory while `protocolId` is not? - Shouldn't `id` and `protocolId` be the same field/value? -- What does "format" of the ss58 address format mean? +- The ss58 address format should also be a PSP. - In the (kusama) JSON file, the `property` field has certain key/value pairs, but the Substrate code accepts anything. This behaviour makes sense in terms of the genesis parameters, since those values just get inserted into the state storage. But how can `property` be useful if those values are not predefined? - What does the second object in `"genesis"` > `"raw"` do? See: `"raw": [{},{}]` - Since Polkadot has not been released yet, why is `"consensusEngine"` a legacy field? From 1ddadda162c0c86a8065bfca1bf361e8214f785f Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Thu, 5 Dec 2019 16:14:23 +0100 Subject: [PATCH 09/11] adjust todo --- PSPs/drafts/psp-5.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index 848b49a..dd11e46 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -4,7 +4,7 @@ * **Authors:** Fabio Lama * **Status:** Call for Feedback * **Created:** 2019-12-05 -* **Reference Implementation:** https://github.com/w3f/polkadot-spec/blob/master/genesis-state/kusama/ksmcc3/kusama.json +* **Reference Implementation:** https://github.com/paritytech/polkadot ## Summary @@ -93,4 +93,15 @@ This Polkadot Standards Proposal is placed in the public domain as defined in th - What does the second object in `"genesis"` > `"raw"` do? See: `"raw": [{},{}]` - Since Polkadot has not been released yet, why is `"consensusEngine"` a legacy field? - What should be defined in the header value "Reference Implemenation"? -- What's the logging verbosity for telemetry endpoints? \ No newline at end of file +- What's the logging verbosity for telemetry endpoints? +- Telemetry log levels: +- Those telemetry log levels are implementation specific and probably do not need to be standardized. Should the log levels be part of the genesis file? Should telemetry itself be part of the genesis file? If yes, then the behavior of the telemetry endpoint/interfaces must probably be specced, too. +``` +pub const SUBSTRATE_DEBUG: &str = "9"; +pub const SUBSTRATE_INFO: &str = "0"; + +pub const CONSENSUS_TRACE: &str = "9"; +pub const CONSENSUS_DEBUG: &str = "5"; +pub const CONSENSUS_WARN: &str = "4"; +pub const CONSENSUS_INFO: &str = "1"; +``` \ No newline at end of file From 1a25daa6865e80fcce7d00955d4e0ef03a0c5604 Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Thu, 5 Dec 2019 16:28:24 +0100 Subject: [PATCH 10/11] format tables --- PSPs/drafts/psp-5.md | 38 ++++++++++++++++++-------------------- 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index dd11e46..950e93f 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -20,28 +20,28 @@ The Polkadot Runtime Environment Specification describes how genesis parameters The genesis file must be represented in the following format: -|Name |Type |Mandatory|Description| -|------------------|-------------------------|---------|-----------| -|name |String |YES |The name of the chain network| -|id |String |YES |Client-side parameter for logging, directory names, etc | -|bootNodes |[String] |YES |An array containing one or multiple `libp2p` [Multiaddresses](https://docs.libp2p.io/concepts/addressing/), including protocol id and multihash| -|telemetryEndpoints|[[String, Int]]|NO |An array of zero, one or multiple telemetry endpoints, where the inner array(s) contain(s) two values. The first value is an address with the full URL scheme and the second value is a number indicating the logging verbosity.| -|protocolId |String |NO |The identifier of the chain network, which is sent with each request| -|properties |Object->Properties |NO |Metadata for the chain network| -|consensusEngine |null |YES |Never used; left only for backward compatibility| -|genesis |Object->Genesis |YES |Contains the genesis parameters| +|Name |Type |Mandatory|Description| +|------------------|------------------|---------|-----------| +|name |String |YES |The name of the chain network| +|id |String |YES |Client-side parameter for logging, directory names, etc | +|bootNodes |[String] |YES |An array containing one or multiple `libp2p` [Multiaddresses](https://docs.libp2p.io/concepts/addressing/), including protocol id and multihash| +|telemetryEndpoints|[[String, Int]] |NO |An array of zero, one or multiple telemetry endpoints, where the inner array(s) contain(s) two values. The first value is an address with the full URL scheme and the second value is a number indicating the logging verbosity.| +|protocolId |String |NO |The identifier of the chain network, which is sent with each request| +|properties |Object->Properties|NO |Metadata for the chain network| +|consensusEngine |null |YES |Never used; left only for backward compatibility| +|genesis |Object->Genesis |YES |Contains the genesis parameters| **Object:** Properties -|Name |Type |Mandatory|Description| -|------------------|-------------------------|---------|-----------| -|ss58Format |Int |NO |The format of the [ss58 address format](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58))| -|tokenDecimals |Int |NO |The decimal precision of the native token| -|tokenSymbol |String |NO |Symbol of the native token| +|Name |Type |Mandatory|Description| +|-------------|------|---------|-----------| +|ss58Format |Int |NO |[SS58 Address Format](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58))| +|tokenDecimals|Int |NO |The decimal precision of the native token| +|tokenSymbol |String|NO |Symbol of the native token| **Object:** Genesis -|Name |Type |Mandatory|Description| -|------------------|-------------------------|---------|-----------| -|raw |Object[String:String] |YES |The key/values pairs required for the runtime| +|Name|Type |Mandatory|Description| +|----|---------------------|---------|-----------| +|raw |Object[String:String]|YES |The key/values pairs required for the runtime| **Example:** ``` @@ -93,8 +93,6 @@ This Polkadot Standards Proposal is placed in the public domain as defined in th - What does the second object in `"genesis"` > `"raw"` do? See: `"raw": [{},{}]` - Since Polkadot has not been released yet, why is `"consensusEngine"` a legacy field? - What should be defined in the header value "Reference Implemenation"? -- What's the logging verbosity for telemetry endpoints? -- Telemetry log levels: - Those telemetry log levels are implementation specific and probably do not need to be standardized. Should the log levels be part of the genesis file? Should telemetry itself be part of the genesis file? If yes, then the behavior of the telemetry endpoint/interfaces must probably be specced, too. ``` pub const SUBSTRATE_DEBUG: &str = "9"; From 4267e458d822bc818ec3aab5f998f506fc5d6ef9 Mon Sep 17 00:00:00 2001 From: lamafab <42901763+lamafab@users.noreply.github.com> Date: Thu, 5 Dec 2019 16:41:27 +0100 Subject: [PATCH 11/11] fixed formatting --- PSPs/drafts/psp-5.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/PSPs/drafts/psp-5.md b/PSPs/drafts/psp-5.md index 950e93f..0e84c75 100644 --- a/PSPs/drafts/psp-5.md +++ b/PSPs/drafts/psp-5.md @@ -31,20 +31,23 @@ The genesis file must be represented in the following format: |consensusEngine |null |YES |Never used; left only for backward compatibility| |genesis |Object->Genesis |YES |Contains the genesis parameters| -**Object:** Properties +Object: Properties + |Name |Type |Mandatory|Description| |-------------|------|---------|-----------| |ss58Format |Int |NO |[SS58 Address Format](https://github.com/paritytech/substrate/wiki/External-Address-Format-(SS58))| |tokenDecimals|Int |NO |The decimal precision of the native token| |tokenSymbol |String|NO |Symbol of the native token| -**Object:** Genesis +Object: Genesis + |Name|Type |Mandatory|Description| |----|---------------------|---------|-----------| |raw |Object[String:String]|YES |The key/values pairs required for the runtime| **Example:** -``` + +```json { "name": "Kusama CC3", "id": "ksmcc3", @@ -86,6 +89,7 @@ Multiple genesis files can be found in the Polkadot Runtime Environment specific This Polkadot Standards Proposal is placed in the public domain as defined in the [CC0 1.0 Universal (CC0 1.0) Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/). ## TODO + - Why is the client side `id` mandatory while `protocolId` is not? - Shouldn't `id` and `protocolId` be the same field/value? - The ss58 address format should also be a PSP. @@ -94,7 +98,8 @@ This Polkadot Standards Proposal is placed in the public domain as defined in th - Since Polkadot has not been released yet, why is `"consensusEngine"` a legacy field? - What should be defined in the header value "Reference Implemenation"? - Those telemetry log levels are implementation specific and probably do not need to be standardized. Should the log levels be part of the genesis file? Should telemetry itself be part of the genesis file? If yes, then the behavior of the telemetry endpoint/interfaces must probably be specced, too. -``` + +```rust pub const SUBSTRATE_DEBUG: &str = "9"; pub const SUBSTRATE_INFO: &str = "0"; @@ -102,4 +107,4 @@ pub const CONSENSUS_TRACE: &str = "9"; pub const CONSENSUS_DEBUG: &str = "5"; pub const CONSENSUS_WARN: &str = "4"; pub const CONSENSUS_INFO: &str = "1"; -``` \ No newline at end of file +```