From 3bf6522f2fe5d360a64f3682a4c19baa18de88c8 Mon Sep 17 00:00:00 2001 From: vuittont60 <81072379+vuittont60@users.noreply.github.com> Date: Fri, 13 Oct 2023 18:45:06 +0800 Subject: [PATCH] docs: fix typo (#2049) --- docs/RFPs/a-and-v-topology.md | 4 ++-- docs/RFPs/epassport-zk-validation.md | 2 +- docs/RFPs/identity-directory.md | 2 +- docs/RFPs/ksm-tipping-button.md | 2 +- docs/RFPs/php-scale.md | 2 +- docs/RFPs/polkadot-collator-setup.md | 2 +- docs/RFPs/staking-rewards-collector-front-end.md | 2 +- docs/RFPs/uncollateralized-stablecoin-research.md | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/RFPs/a-and-v-topology.md b/docs/RFPs/a-and-v-topology.md index 18b0ec67aaa..507c9a5428d 100644 --- a/docs/RFPs/a-and-v-topology.md +++ b/docs/RFPs/a-and-v-topology.md @@ -9,9 +9,9 @@ This Request for Proposals is _closed_, meaning we are not looking for any more ## Project Description :page_facing_up: -A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficienct block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators. +A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficient block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators. -The full mechanism is described in [the host specification](https://spec.polkadot.network/chapter-anv). In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validitiy of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain. +The full mechanism is described in [the host specification](https://spec.polkadot.network/chapter-anv). In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validity of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain. Currently, the gossip network among the relay chain validators does not make use of the public assignment of a the first subgroup of validators to a particular parachain. Instead, the candidate block is passed around the network until it reaches 2/3+ of approvals, causing an additional delay in the process of finalization of the candidate. diff --git a/docs/RFPs/epassport-zk-validation.md b/docs/RFPs/epassport-zk-validation.md index 60609bf07d7..301ff0a4474 100644 --- a/docs/RFPs/epassport-zk-validation.md +++ b/docs/RFPs/epassport-zk-validation.md @@ -52,6 +52,6 @@ Later, the proof is uploaded on-chain, and the chain logic performs verification * **Estimated Duration:** 1 month * **Costs:** 20,000 kUSD -The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furhtermore, countries are expected to publish the revocations of any compromised certificates. +The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furthermore, countries are expected to publish the revocations of any compromised certificates. It is important that both prover and verifier circuits are updated accordingly - else the proof won't match. diff --git a/docs/RFPs/identity-directory.md b/docs/RFPs/identity-directory.md index 0e469da1a23..5bc40ce5164 100644 --- a/docs/RFPs/identity-directory.md +++ b/docs/RFPs/identity-directory.md @@ -51,7 +51,7 @@ The individual events and positions in the various columns should be **linkable* #### Default Plugins - `basic info`: a column with basic information about an account, similar to the sidebar on Polkadot JS Apps UI. Should discern between registrars - it should list each registrar who verified this identity and the verification level they gave (i.e. KnownGood vs KnownBad etc.) -- `governance`: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as decribed above, i.e. `governance@477723`. The column should **clearly** mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member). +- `governance`: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as described above, i.e. `governance@477723`. The column should **clearly** mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member). - `treasury`: a history of an account's interactions with the treasury - tip proposals and endorsements, treasury proposals and grant wins, votes on TP motions if user was council at the time (and clear marks if the user FAILED to vote on a TP motion during his activity as councilor). - `validator`: showing the history/summary of the account's participation in securing the network #### Optional Plugins diff --git a/docs/RFPs/ksm-tipping-button.md b/docs/RFPs/ksm-tipping-button.md index 5debd7c4631..6142d0b3f6f 100644 --- a/docs/RFPs/ksm-tipping-button.md +++ b/docs/RFPs/ksm-tipping-button.md @@ -23,7 +23,7 @@ The tip begins its closing process (a countdown) when more than a half of counci ## Proposal -The Kusama Tip Button sould be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner. +The Kusama Tip Button should be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner. Before the user interacts with the button, the button's embedded code should: diff --git a/docs/RFPs/php-scale.md b/docs/RFPs/php-scale.md index 0fa1df40061..1c6161ce63c 100644 --- a/docs/RFPs/php-scale.md +++ b/docs/RFPs/php-scale.md @@ -15,4 +15,4 @@ The SCALE codec is the de-factor encoding method in Substrate-based chains. It i The deliverable should be a standalone SCALE codec package, hosted on Packagist. It can (but does not have to) depend on existing Base58 packages already present on Packagist.org. -The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusivley a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone. +The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusively a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone. diff --git a/docs/RFPs/polkadot-collator-setup.md b/docs/RFPs/polkadot-collator-setup.md index 14e1aa2ace4..fc63b89f51c 100644 --- a/docs/RFPs/polkadot-collator-setup.md +++ b/docs/RFPs/polkadot-collator-setup.md @@ -20,7 +20,7 @@ I understand it might be tricky to bundle all the parachain launch setups into o 1. Have a single collator ansible role, and each branch would correspond to a specific parachain 2. Have multiple ansible roles, and the main.yml in the project root to coordinate which roles get deployed. -I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independant chains without meddling with git branching too much. +I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independent chains without meddling with git branching too much. ## Deliverables :nut_and_bolt: diff --git a/docs/RFPs/staking-rewards-collector-front-end.md b/docs/RFPs/staking-rewards-collector-front-end.md index c717e0498dc..ed1d64a38ca 100644 --- a/docs/RFPs/staking-rewards-collector-front-end.md +++ b/docs/RFPs/staking-rewards-collector-front-end.md @@ -14,7 +14,7 @@ This Request for Proposals is _closed_, meaning we are not looking for any more The [staking-rewards-collector](https://github.com/w3f/staking-rewards-collector) is a tool to gather staking rewards for given addresses and cross-reference those with daily price data. This is a very useful tool for every validator and nominator in the ecosystem. However, since it has currently a CLI and requires some technical knowledge to set up (git, nodejs, yarn). A front-end hosted on a website could help many users getting access to this tool and enjoy the benefits. -The backend is already written in javascript, this should make it quite easy to host as a website and develope a front-end. +The backend is already written in javascript, this should make it quite easy to host as a website and develop a front-end. ## Deliverables :nut_and_bolt: diff --git a/docs/RFPs/uncollateralized-stablecoin-research.md b/docs/RFPs/uncollateralized-stablecoin-research.md index 33bf291b45f..d89129c7c8c 100644 --- a/docs/RFPs/uncollateralized-stablecoin-research.md +++ b/docs/RFPs/uncollateralized-stablecoin-research.md @@ -59,6 +59,6 @@ The milestones below are just an initial draft. The milestones can be structured | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | -| 1. | Implement PoC| Implement the previous reasearch as ink! Smart contract or pallets | +| 1. | Implement PoC| Implement the previous research as ink! Smart contract or pallets | | 2. | UI (optional) | Implement a basic UI that can be used for testing |